AN for runtime RAM/Stack usage of the STM32 application

[darla14]

Posted on January 21, 2016 at 17:20

HI, 

Is there any Application Note for runtime stack and RAM utilization of the STM32 application .Any tool specific to Nucleo for evaluating the application?Is STM Studio meant for that?Rgds,R #!stm32-!cubemx #stm32cubemx #nucleo #eclipse

[Tesla DeLorean]

Posted on January 22, 2016 at 00:52

Not sure this needs to be STM32 specific, classic methods for tracking heap and stack usage should be applicable here.

Are you using dynamic allocation? Most RAM gets statically allocated in embedded apps due to the failures prevalent with dynamic allocations fragmenting or leaking.For the stack, I tend to just mark it and periodical check the maximal depth. Some tools provide call-chain/stack-depth analysis in the linker. Others add prologue code to check the stack as auto/local variables are allocated.

[darla14]

Posted on January 22, 2016 at 04:38I am not using dynamic memory allocation.For the stack, I tend to just mark it and periodical check the maximal depth>> On what basis you change the stack size for checking the depth.By putting some value in the linker file(IAR) and periodically decreasing it till you get some hard-fault or something like that.

[Tesla DeLorean]

Posted on January 22, 2016 at 17:49

I usually don't wait for it to Hard Fault, but I do have a handler that outputs diagnostic info if it does, as this works a lot better than while(1). You could place the stack toward the bottom of RAM, I'd expect it to Hard Fault as it drops through the bottom into the ROM space.

I have my code output information about the stack depth, and via an interactive test console. You should have a pretty good idea how deep it needs to be to start with, IRQ Handlers can push it deeper as the linker can't really provide much static analysis of such things. I don't use IAR, in Keil we'd start with a stack size in startup_stm32fxx.s that will work with kinds of local allocations we are using. GNU/GCC tends to stick the stack at the very top of RAM which can mask a lot of heap/stack issues. The problem moving from a PC programming environment is that people allocate huge amounts of local/auto variables.