2021-04-05 05:36 AM
Hi. I was trying to test my code to see if I have enough stack. I realized in my project's .ld file stack size is defined as:
_Min_Heap_Size = 0x200;
_Min_Stack_Size = 0x400;
However, I tried to test this to see if stm32cubeide gives error when I tried to exceed defined memory size. I declared a local variable inside a function and checked stack pointer. When I call my function inside main, stack pointer seems to go somewhere it shouldn't. For example 0x1FFFFFF6 which is memory domain for code segment and not SRAM. Same thing happens when I declare a local variable inside ISR.
My question is why stm32cubeide do not throw an error when I pass the defined stack size? Do I have to test max occupied stack for each code manually?
Thanks.
Solved! Go to Solution.
2021-04-05 06:43 AM
Hello @LLOLO.1,
Peak stack consumption is a runtime issue. It can't easily be detected at compilation time. Stack overflow is a runtime issue that's usually best detected using dynamic program analyzer (like Valgrind for example). STM32CubeIDE is and IDE+toolchain, and not a dynamic software analyzer.
Some toolchains (like MDK-ARM for example) generate static estimated stack usage. GCC can be used to generate such reports (peak stack usage) using the -fstack-usage flag but beware that the resulting number are an estimated minimum if callbacks/function pointers, etc... are used (they introduce unknown stack usage).
I hope this helps!
BeST regards,
Walid
2021-04-05 06:43 AM
Hello @LLOLO.1,
Peak stack consumption is a runtime issue. It can't easily be detected at compilation time. Stack overflow is a runtime issue that's usually best detected using dynamic program analyzer (like Valgrind for example). STM32CubeIDE is and IDE+toolchain, and not a dynamic software analyzer.
Some toolchains (like MDK-ARM for example) generate static estimated stack usage. GCC can be used to generate such reports (peak stack usage) using the -fstack-usage flag but beware that the resulting number are an estimated minimum if callbacks/function pointers, etc... are used (they introduce unknown stack usage).
I hope this helps!
BeST regards,
Walid
2021-04-05 07:32 AM
GNU/GCC as used by ST typically parks the stack frame at the top of RAM, and the simplistically allocator tries to manage the heap in between the end of the statics and the bottom of the stack.
If you want to monitor/check stack depth you'd do better to use a fill pattern you can check at key routines or under the 1KHz ticker.