We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
From the following link I have understood the compiler analyses the program and sets the stack size for the 8051. I am seeing a stack overlow when one ISR interrupts a lower priority ISR. If the compiler analyses the program and sets the stack, to a size it deems adequate, then how can it overflow ? I am using a 8051 and a Keil compiler.
Any help would be appreciated.
Thanks,
Rochus
the linker does NOT 'analyze' the stack size, it just allocates whatever ram is left as stack
Okay. That is what I suspected initially, however the following two points diverted my understanding:
1 ) This is an excerpt from the link.
"The Keil C51 C Compiler works with the LX51 Linker to store function arguments and local variables in fixed memory locations using well-defined names (so that function arguments are easily passed and accessed). The linker analyzes the structure of the program and creates a call tree which it uses to overlay the data segments containing local variables and function arguments. This technique works extremely well and provides the same efficient use of memory as a conventional stack frame. It is sometimes called a compile-time stack since the stack layout is fixed by the compiler and linker. An advantage of the compile-time stack is that arguments and local variables are accessed directly using fixed memory addresses (which is very fast on the 8051). Typical stack-based accesses are indirect and execute more slowly on the 8051."
2)Also I have added code without adding extra variables to DATA, and it has incurred link errors. I believe this is even without the use of static variables. This gave credence to point 1.
I have yet to reconcile these points to get a solid understanding. I would like an answer to helps me reconcile these points.
I am used to the typical method declaring the stack segments in the linker description file, and clearing it in the runtime code.
The material you quote explains how C51 manages to keep almost all the data (function arguments, local variables) out of the actual stack, by applying static call tree analysis. You can help it by banking registers for interrupt handlers. But some data still end up on the stack, most notably the return addresses for CALL/RET and interrupts. Those occupy whatever remains of your IDATA.