'Stack Overflow on 17c42'
I'm suffering from stack overflows on a 17c42 (I put a check of STKAVL
in my RTCC Timer Interrupt handler and I output an error code on a 7
segment display when detected). BUT, I've done a thorough analysis of
my software and there is no way I should be overflowing the 16 word
stack. I'm using three timer interrupts (RTCC, Timer 1/2, and Timer 3)
plus the Port B interrupt on change (although no port B pins are
changing when this occurs), and I'm not enabling interrupts in any of my
interrupt handlers (GLINTD remains set until the RETFIE at the end of my
As I understand the spec sheet, an interrupt and a call each use one
word of the 16 word stack. There isn't anything else that affects the
stack is there? Also a "pending" interrupt (one asserted while
interrupts are disabled) does not use any stack - the corresponding
interrupt request bit is merely set - correct? I've tallied the max
stack usage of all my routines and I should be using at most 10 slots.
The other thing that's puzzling is that the time between reset and when
the overflow occurs varies. Given the nature of my software (a timer
application), its execution should be very deterministic. I would
expect this stack overflow to be repeatable and to see a pattern in its
timing. I think I'm missing something. Any thoughts?
|Jim Durand <gte.net> wrote: durandj
> I'm suffering from stack overflows on a 17c42 .... BUT, I've done
> a thorough analysis of my software and there is no way I should be
> overflowing the 16 word stack.
Nevertheless, Jim, you ARE overflowing it... So your analysis
must not have been thorough ENOUGH.
> As I understand the spec sheet, an interrupt and a call each use one
> word of the 16 word stack.
> There isn't anything else that affects the stack is there?
> Also a "pending" interrupt (one asserted while interrupts are
> disabled) does not use any stack - the corresponding interrupt
> request bit is merely set - correct?
> I've tallied the max stack usage of all my routines and I should
> be using at most 10 slots. .... I think I'm missing something. Any
Well... Obviously, your software isn't doing what you intend.
Do you perform any direct writes to the Program Counter?
Perhaps there's a bug in one of them and you're accidentally
pointing the PC at a subroutine call.
Do you have an emulator? If so, I can suggest some debugging
techniques that should help you isolate the problem pretty
quickly... Let me know.
=== Meet other PICLIST members at the Embedded Systems Conference:
=== 6:30 pm on Wednesday, 1 October, at Bytecraft Limited's booth.
=== For more information on the Embedded Systems Conference,
=== see: http://www.embedsyscon.com/
=== Andrew Warren - ix.netcom.comfastfwd
=== Fast Forward Engineering - Vista, California
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- New search...