Lpc2000

--- In lpc2100@yahoogroups.com, "Lewin A.R.W. Edwards" <larwe@l...> 
wrote:
> It is preferable to analyze stack requirements beforehand, and 
monitor 
> them during worst-case usage testing, if possible. Sometimes I add 
code 
> to my watchdog-kicking code that checks for pre-RTL-init signature 
at 
> the bottom of stack; if it's not there, I write a stack overflow 
> diagnostic to the product log and stop kicking the dog to force a 
reset.

I have to agree with Lewin, in the ARM tools at least there's a 
significant performance penalty for turning on software stack 
checking - I have seen 15% performance drop. This is due to 
additional code per function call, and having a register dedicated 
to holding the stack limit, which leads to more spill-out onto the 
stack.

The big problem with enabling software stack checking during testing 
then disabling for production is that you should really run all your 
tests again - otherwise you're not releasing the product that you 
tested.

In my experience, unless someone is trying to instantiate a 20K C++ 
object on the stack, its usually an interrupt mode stack that 
overflows rather than the application stack. Checking for signatures 
at the bottom of the stack area can be extended to cover FIQ and IRQ 
mode stacks, and is a relatively low-overhead operation.

One nice feature about this is that generally interrupt code keeps 
running long after application code has found new and exciting ways 
to occupy itself in non-existent memory, so placing the stack 
checking here can rescue the whole system.

Incidentally... I've seen watchdog timer reload code in interrupt 
handlers, but for the reason I've mentioned above that may not 
protect against dead application code. Isn't it better to reload the 
watchdog timer at strategic points in the application? That way, the 
watchdog event kicks in if the application locks up.

Peter.