Problems with libraries and delays

[aek]

quote:

---

Could you confirm that for a 18F452, with 16bit ROM pointers, it is always correct to use slp86lta.lib library ?

---

Yes, that should be fine, as long as your particular chips are the revision that is covered by the PICC-18 errata.

You can always check the return codes for OSCreateTask() to see if it was successful ... what return code did you get?

You would use slp86ltb.lib if you weren't calling Salvo services from the ISR level.

------------------

[This message has been edited by aek (edited June 07, 2005).]

[lucicop2001]

I get result 0 to all OSCreateTask, and I suppose this is the value for OSNOERR ? Still, Siren_Init is not called !

------------------
Lucian

[aek]

OK, we know that Siren_Active() is successfully created as a task, because it runs / starts.

The calls to OS_Timer() do not behave normally.

1) I presume you have global interrupts enabled all the time?

2) As I mentioned before, all Salvo needs for good timing is for OSTimer() to be called at a particular rate. If it's failing (e.g. siren goes ON and never goes off), that means that the task never runs again after timing out. Assuming priorities are not a problem, that means that the task is "stuck" in the delayed state.

3) Here's what I would do -- take this code (only) and run it in MPLAB's SIM. Watch OStcbArea[], specifically the tcb for this particular task. Break on OSTimer(). Watch the delay field in the task's tcb. Once the task is delayed (i.e. after the siren goes ON), its delay field should decrement each time OSSched() runs after OSTimer() is called. After the last decrement, Siren_Active() should run again and "fall into" the } while(--i).

Zip up a simple project just with this task and email it to me, and I'll run it here in the SIM. Note that I am assuming that your salvocfg.h is as below (only those 8 lines), you haven't modified any Salvo source code, etc.

------------------

[lucicop2001]

Hi Andrew,

I have sent you the source code and in the meantime I have tested it with MP SIM. Now it looks like it reaches Siren_Active, but I can't see OStimerTicks incrementing after the first OS_Delay, and when it enters the second time into this function, it goes to while (counts), not to the do...while cycle... Do you have the same results ?

------------------
Lucian

[aek]

Hi Lucian.

I was unable to open your project because it uses MS SourceSafe and MPLAB can't open a project like that if it's not configured for Source Safe (which we don't use).

Anyway, I built up a project from scratch using your code in MPLAB v7.10. I made a few small changes, but nothing major. Did you have PICC-18's Memory Model set to Large (the default) and the 24-bit pointers deselected (the default) in your MPLAB project when you used the slp86lta.lib library?

I get an ON time of 4s and an OFF time of 3s for the Siren. Seems to work nicely. Is this correct?

------------------

[This message has been edited by aek (edited June 08, 2005).]

[aek]

Oh, in the SIM, the SIREN turned off (for good) at 175s. Is this correct?

------------------

[aek]

quote:

---

The failure is that the siren keeps pulsing, but not for 3s/2s as intended, but rather 4s (sometimes 6s)/2s, and not for the big period of 3 minutes, but forever.

---

Minor nit: you've coded the loops with do { ... } while (i--);

Therefore you get 4s On and 3s Off, which is correct.

Perhaps you wanted do { .. } while (--i);? That would give 3s On and 2s Off ...

------------------

[This message has been edited by aek (edited June 08, 2005).]

[lucicop2001]

Hi Andrew,

You have used the 86lta.lib library ? 175s is correct (should have been OStimerTicks <= ticks in order to have 178s), but with the current code, it is correct, as it removes the silent period from the end, 2s and another pulse (3s).

Yes indeed, it should have been (--i) for 3s and 2s respectively. I will try again myself, even if I already tried it without success.

The compiler is configured for Large memory model and 24-bit pointers deselected. But in my code, it doesn't start at all now...

Could you please send back the code as you tested it in order for me to get it tested and see if I have the same results as you ? If this will be the case, I will check for the differences with my actual code, to see where it is not working.

Thank you very much for taking the time to test it and tell me the results !

Regards,

------------------
Lucian

[lucicop2001]

Hi Andrew,

Have you had time to watch my project ? I investigated it, and even without the other tasks, it doesn't run normally. It's a very strange behaviour and I suspect that it is something from the kernel : something i misconfigured...

Please inform me as soon as you have tested the program I sent you.

Thank you !

Regards,

------------------
Lucian

[aek]

Hi Lucian.

The 86l library is the correct one for that chip.

To verify, enable select "Display verbose output" under PICC-18's Global tab in the build Options.

You'll get this line towards the end of the build:

code:

---

hlink.exe -z -ol.obj -ppowerup=00h,intcode=08h,intcodelo=018h,init,end_init -ACOMRAM=00h-07Fh 
-ptemp=COMRAM -ARAM=0-0FFhx6 -ABIGRAM=0-05FFh -pramtop=0600h -ACODE=00h-03FFFh,04000h-07FFFh
-pconfig=0300000h,idloc=0200000h,eeprom_data=0f00000h -pconst=end_init+0600h -prbss=COMRAM,rbit=COMRAM,rdata=COMRAM,nvrram=COMRAM,nvbit=COMRAM 
-pstruct=COMRAM -pnvram=-600h -pfarbss=8000h 
-pintsave_regs=BIGRAM,bigbss=BIGRAM,bigdata=BIGRAM -pdata=RAM,param -pidata=CODE,irdata=CODE,ibigdata=CODE -Q18F452 -h+lucian_aek.sym 
-mC:DOCUME~1ADMINI~1LOCALS~1Temp\_US.AAF -E -EC:DOCUME~1ADMINI~1LOCALS~1Temp\_US.AAA -ver=PICC18#V8.30 C:HTSOFTPIC18LIBpicrt86l.obj C:lucianuser.obj C:luciansiren.obj 
C:lucianmain.obj C:salvosrcmem.obj C:salvolibhtpicc18slp86lta.lib C:HTSOFTPIC18LIBpic86l-c.lib

---

Note the pic86l-c.lib at the end. That's the PICC-18 library that's being linked in. The Salvo libraries use a similar nomenclature -- that's why "86l" is common to both library names.

------------------

[This message has been edited by aek (edited June 09, 2005).]