i am not sure if the stack is overflow in my project. thank a lot!
Even if you don't notice problems you always should have an idea about stack usage, it is the only way to rely on your program. The used stack is a dynamic characteristic so you only get this information at execution time. I will assume large memory model... The first step is determine the maximum available stack, you can get this value from map file, look for STACK keyword, for example: IDATA 0030H 0001H UNIT STACK The space between 30H and the end of internal memory (128 or 256 bytes)will be your available stack. 1/ Firts option is manual calculation: determine the function call tree and add 2 bytes per call (5 bytes if you use interbank function call). In addition add the stack usage of ISR (more calls and push/pop instructions) 2/Other option is directly read the SP value at the deepest points of your call function tree. You can estimate the risks. 3/ A third option, that a friend touch, me is very interesting. You have to initialise the IDATA with a known value "0x55". Later, at any point of ccall function tree, you can scan the idata and determine where the 0x55 appears and so the unused stack. This method even determine the stack usage of ISR (typically more complicate) This last method is still more powerfull... If you get a crash or a reset (perhaps you have a watchdog) and in systems where there is no RAM initialisation you can at start up take the "photo" of the crash and determine the stack usage. I hope all this useful for you. Thanks
Thanks very much, but why keil c51 don't check the overflow of stack(or i don't find it)? Any difficult there to realize this point? thanks again!
why keil c51 don't check the overflow of stack And, what exactly should the compiler do if there IS a stack overflow? Jon
I think keil c should give us a warnning at least. because: 1. it can locate the start address of stack; 2. it can output the call tree( in *.m51); 3. the compiler certainly knows operations of push and pop instructions(except programmer's assemble code). so, keil c51 can get the deepest(include interrupt routine) stack length and should warn us the risk of stack overflow. welcome to give advice or comments. thanx!
I agree. If the compiler/linker could work together to print out a max known stack usage for each branch of the overlay map, I would know the exact amout of bytes I could throw over to my communication buffers.
I have a qustion: What is usage of the five bytes of ISR? And when it enter ISR in main procedure, how do Keil C51 to manager stack? push five bytes directly? Thx
I think keil c should give us a warnning at least. because: 1. it can locate the start address of stack; 2. it can output the call tree( in *.m51); 3. the compiler certainly knows operations of push and pop instructions(except programmer's assemble code). AND the "compiler" does NOT know the possibilities of interrupts interrupting interrupts and the number of reentrancies of those reentrant function some of you use. By the way The compiler does not know diddlysquat in this respect, only the linker does. I would rather have no answer than an answer that may be wrong. stack overflow is about the easiest to check, use yout ICE or whatever to fill the stack area with something, run the thing and if all is overwritten you have an overflow. Then find the maximum stack usage of interrupts at all IP priorities and add the most of any at each IP priority. If there is room for that you are safe. Erik
What is usage of the five bytes of ISR? What 5 bytes? Erik
"What is usage of the five bytes of ISR?" Nobody said anything about five bytes. What five bytes are you talking about? "And when it enter ISR in main procedure, how do Keil C51 to manager stack? push five bytes directly?" If you write your ISR in C, then the compiler generates PUSH/POP instructions to save and restore whatever processor context is required. If you want to "see" it in action, then generate an assembly listing.
In C51.pdf it is said: The contents of the SFR ACC, B, DPH, DPL, and PSW, when required, are saved on the stack at the function invocation time. And I try to analyze stack while enterd ISR function, it make me so comfused. I want to konw what infomation is pushed to stack while enter ISR. thx for you so quickly replies. I am a fresh, i want to study assemble. wu~~~
A dynamic stack fill test assumes you are able to force the execution path down the deepest path of control. There are two problems in doing so: (1) being able to force to that path while the system is running, and (2) even knowing what that path is in the first place. Note that (2) is exactly the same information the OP requested: an output of the static analysis already done by the linker indicating the the max-depth path down the call tree. The information doesn't have to be complete to be useful. For instance, if the linker gives me the depth of the main body, plus that of each interrupt function, I can decide for myself what the actual depth it. Sure, the linker doesn't know when the interrupts occur, but that doesn't mean the information is does have is wrong. It just needs a little more analysis. And having the linker provide this information is a lot faster and more reliable than doing it manually. The occasional bit of generated code or library routine will throw in a PUSH/POP which aren't obvious from inspecting the source. Only the toolchain can really produce the right answer. I've wanted this feature from every compiler I've ever used. It's particular appropriate for C51, as the tools already do the analysis, and the usual reasons for not providing the information -- recursion and reentrant functions -- are much, much less common than in workstation-style code.
one issue Those that believe that a global variable is worse than death will have more trouble re stack calculation than normal people. If you transfer more in a call than the registers can hold that affect the stack as well. Erik
I use glabol variables as normal programming in C51. Bug I still have a question about stack while enter ISR, for example: normal run in main() that stack base is 0x30H, SP is 0x33, that means 4 bytes in stack as sequence as "0xFF00, 0xFE00". And now it enter ISR, so push "A, B, DHP, DHL, PSW" to stack. So is it SP 0x33 + 5 = 0x38? It seems so strange in my program.
And now it enter ISR, so push "A, B, DHP, DHL, PSW" to stack. So is it SP 0x33 + 5 = 0x38? It seems so strange in my program. ? When an interrupt happens some process is in progress in the main, let us say the following happens main: load dptr interrupt main: load what dptr points to Now, if the interrupt uses the dptr (changes its contents) what would happen if it did not save the DPTR at entry and resore it on exit. Erik
I have solve my problem. I compile c source file with parameter "SRC" to get ".SRC" assemble file. It pushes ACC, B, DPH, DPL and PSW to stack at the begin of ISR