The stack starts at the highest address of its allocation and grows to lower memory.
I don't think that there's anything in the arm processor core that is dedicated to trapping a stack that has grown too big.
But there are ways to see how much of your allocated stack space is being used.
My development environment, Rowley Crossworks, likes to put guard words 0xFACEFEED at either end of the stack. You can periodically check if those words are intact, and if not you know the stack has grown too long (or you have wrongly popped too much off the stack - very unlikely as the primary cause of failure if you're using a high-level language such as C). But it isn't foolproof because:
- You only know after the event that the guard-word has been clobbered
- It is possible, if your code allocates space on the stack but then does not use all of it, for the stack to grow too big but not clobber the guard word.
But I like to pre-load the space between those 0xFACEFEEDs with a known value, say 0xFE. Then I can look from the end of the stack and see the first byte that isn't the starting value, and I know I have used stack up to that point. Again this doesn't prevent the stack from growing too large.
What could you do?
I suppose you could put a hardware debug data write breakpoint on memory just beyond the stack. That should force a break at the point the stack guard-word is overwritten.
Maybe you could do the same with the memory-protection unit. I don't know if that will trigger a double-fault, so it might be difficult to recover the state when the fault occurred.
Or the check could be done automagically in software. I think the Keil environment has a way to check at every context-switch according to:
http://www.keil.com/support/man/docs/rlarm/rlarm_ar_cfgstchk.htm
(google search for "keil arm stack overflow"). But then that's for multi-threaded code using their RTX. The way you've written the question, you might be only using one thread.
Hope this helps,
Danish
