Stack Overflows Under Emulation

[jmark1m]

Using Salvo 3.2.3 pro (latest) and HiTech PICC (latest) I have my program compiling and linking. I am using a PIC17C756A with PICE-MC emulator.

When starting the program under emulation the message I get is stack overflow. I have removed everything out of the two tasks I am switching between. They are now basically empty while loops with an OSYield in them. My salvocfg.h file is below,
--------------------------------------
#define MAKE_WITH_SOURCE
#define OSUSE_LIBRARY FALSE
#define OSBYTES_OF_DELAYS 1
#define OSENABLE_MESSAGES FALSE
#define OSEVENTS 0
#define OSLOC_ALL bank1
#define OSTASKS 2
#define OSCOMPILER OSHT_PICC
#define OSTARGET OSPIC17
#define OSUSE_INLINE_OSSCHED TRUE
------------------------------------

I have even attempted to inline OSSched() to reduce the call-return depth. This appeared to work judging from my *.map file and the call graph. For some reason I think that perhaps the Stack Overflow message I am getting from the emulator is misleading and that it may indicate another problem (the schedular sending me into the weeds).

Any ideas on something like this?

Thanks,

Mark Johnson

[aek]

Stack overflow on the PIC (esp. the PIC17, which has a 16-level deep hardware stack) is most likely something else and not stack overflow.

Since you're doing a source-code build you can step right through the Salvo source code to see where it crashes.

Normally I place a breakpoint on the call to OSInit(), and one on the call to OSSched(). Then count how many times through OSSched() you get before it crashes. Then you can usually isolate it.

I'd check interrupts, the WDT, and various other hw-related issues.

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

[jmark1m]

Sorry for not including the pertinant information that I am using a 32Mhz external clock. 500 us is quite a few cycles at that speed.

My isr was as simple as

static void interrupt
tmr0_isr(void) @ 0x0010
{
TMR0H = 0xf0;
OSTimer();
}

I have backed up and am making some progress now. Thanks for all of your help.

[jmark1m]

It appears that sometimes (when it is not a stack overflow) the scedular is forgetting about some of my tasks. After the tasks have been executed once they are never executed again. Is there any way that salvo can lose information about a task?

[aek]

quote:

---

After the tasks have been executed once they are never executed again.

---

and

quote:

---

static void interrupt
tmr0_isr(void) @ 0x0010
{
TMR0H = 0xf0;
OSTimer();
}

---

This ISR is no good because you are failing to clear the interrupt flag (T0IF) from within the ISR. This results in the IF remaining set, and the system is constantly servicing the interrupt. If you look at the int.c in http://www.pumpkininc.com/content/doc/appnote/an-8.pdf,
you'll see this code snippet, that is consistent for all PICs:

code:

---

if (TMR2IE & TMR2IF)
{
  TMR2IF = 0;
  ...

---

Failure to clear the IF flag will cause all sorts of problems. If your other tasks (that are "forgotten") use OS_Delay(), then they will be "forgotten", because the ISR is not getting hit properly and their delays never reach 0.

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

[jmark1m]

I have the WDT disabled. I had some interrupts turned on. Specifically TMR3 to make a call to OS_Timer(). Not sure how this can effect things.

The other issue I have is that sometimes it behaves differently if I step through the code versus let it free-run.

Thanks for your help.

[jmark1m]

I started over today with a simple subset of my program.

It works great with two tasks and OS_Yielding between them. As soon as I turn on interrupts things go bad. Just adding this code

/////////////////////////////////////////
// Setup Timer 0
/////////////////////////////////////////
PS1 = 0; // Prescaler divide by 8
PS0 = 0;
T0CS = 1; // Set Timer 0 Clock Source
T0IE = 1;

causes it to freak out. This interrupt is about 0.5ms. But according to the emulator the interrupt routine itself never gets called before the processor goes into an endless infinite loop of some sort.

[aek]

So what happens if you siolate the TMR0 interrupt further? E.g. in a non-Salvo app? Or if you do something like this:

code:

---

main ()
{
  OSInit();
  ...
  OSSched();
  OSSched();
  while (1) { ; }
}

---

This will likely run through the scheduler twice before the interrupt happens.

Note that (if I understand your code correctly) the TMR0 interrupt does not call any Salvo code (e.g. OSTimer()). Remove the TMR3 call to OSTimer() and try to get the TMR0 stuff to work -- in this case, the TMR0 has nothing to do with Salvo (the ISR is simply serviced, doing nothing) and it doesn't matter what the overlying application is doing.

BTW, Salvo was originaly written for the PIC17C756 (in assembly, no less) so it defintely runs on that part. But I will freely admit that we haven't tested on the PIC17 in a long time.

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

[aek]

quote:

---

It works great with two tasks and OS_Yielding between them. As soon as I turn on interrupts things go bad. Just adding this code

---

OK, re-reading this tells me that there is something wrong with the ISR itself, since simply enabling the ISR should result in the ISR happening, and that's about it. Be sure that you are servicing the ISR (by clearing the interrupt flag) properly or you will re-enter the ISR as soon as you leave it. IIRC w/regard to the PIC17.

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

[jmark1m]

Thanks,

There was something wrong with the compiler locating the interrupt handler in the correct location. This is working now.

Now it is working with 4 tasks and an interrupt calling OSTimer(). It seems very easy to overflow the stack still. I increased the number of tasks to be 5. This fifth task basically did nothing. This caused a stack overflow. Backing off on the period of OSTimer causes this apparent stack overflow to go away. What is the fastest that I can call OSTimer? I had been running at about 500us.