Stack Location

[ignisuti_]

It seems to me that the standard in embedded programming is to have the stack start at the end of RAM.

I've been using a new approach for awhile now that seems to work much better. Please tell me if this is a known strategy that others use and if it has any negative consequences I may have overlooked.

I setup the stack to be located at the start of RAM. With this approach, if the stack ever overflows, it attempts to access protected registers (at least in the Kinetis MCU's I've been using) and therefore causes a hard-fault which is easy to catch and handle gracefully. If that same scenario occurs in the standard/traditional method, the stack can overflow into RAM and cause the code to run-away with unexpected behavior which is simply unacceptable, and even dangerous, in safety critical applications.

[Jorge_Gonzalez]

Hello Joe Kissell:

Please mention the Kinetis part you use.

It seems like a valid approach, but I don't know what you mean with "protected registers". Actually I think you would be accessing nonexistent RAM memory, which causes a busfault.

The disadvantage here is that you only have exactly as much stack memory as you reserved for it. With having the stack pointing to the end of RAM you have [stack reserved memory] + [RAM not used by the application and heap], so this actually reduces the risk of an overflow by having more space.

Regards!

Jorge Gonzalez

[ignisuti_ · Accepted solution]

Jorge,

Thanks for the reply. Those are some valid considerations. I like knowing everything that's going on in my system. If the program uses more stack than I've allocated, I don't want any chance of "undefined" behavior that could happen when the Stack overflows into the RAM area.

I think you're right on it running into nonexistent RAM as opposed to protected registers.

I'm currently using the TWR-KW24D512 development board. According to the Memory Map, that space is for FlexRAM and Programming

acceleration RAM. I don't know much yet about the purpose of those features, but I have tested the Stack overflow theory with this new method and it worked beautifully generating a fault that was captured and handled via logging data to my NonVol section and then resetting the MCU.