STM32 analyze stack content

[serge]

Posted on October 27, 2014 at 22:33

Hi,

My device (in remote location) sometimes is getting hung up. I made sw/hw for servicing guy to take dump of RAM to file, when that happens. How could I analyze dump of MCU call stack to figure out call chain, which was in use on moment of crash? (I suspect HardFault, but not sure). Keil uVision (or other IDE) are displaying call stack nicely, but how to do that from raw memory dump? Is there any tools or documentation available to analyze MC registers and stack? I use STM32F205, and have complete device memory map. Thanks #dump #call-stack #stm32f2

[Tesla DeLorean]

Posted on October 28, 2014 at 02:51

For a simple Hard Fault handler look at the examples by Joseph Yiu, and his Cortex books. Review as the ARM TRM which describes how the fault state and processor registers are expressed.

Walking stacks is non-trivial, you'd want to review the documentation for the ELF object format, DWARF debug symbols format, and the parameter passing, and stack frame scheme (ABI)

[serge]

Posted on October 28, 2014 at 15:17

Hi,

thanks for fast response. Is it possible to force uVision or other IDE to analyze stack dump from external binary file? Do somebody know about any sw tools available to parse stack data, particularly Cortex-M3 stack? Thank you in advance

[chen]

Posted on October 28, 2014 at 17:08

''Do somebody know about any sw tools available to parse stack data''

Not that I know of. ''Is it possible to force uVision or other IDE to analyze stack dump from external binary file?'' Not that I know of. However, you MUST enable the generation of the map file, and save it for each release build. Analysing the stack/raw memory will only mean something if you can identify the function addresses - this is where you need the map file!

[Tesla DeLorean]

Posted on October 28, 2014 at 18:13

However, you MUST enable the generation of the map file, and save it for each release build. Analysing the stack/raw memory will only mean something if you can identify the function addresses - this is where you need the map file!

Well technically a .AXF(.ELF) with debug information will actually contain the code and all the salient details, source line mapping, etc. The .MAP would be helpful for human readable output, or parsing with AWK or PERL, etc. Most of the static analysis tools I'm familiar with are privately held. In a relatively crude fashion one could simply traverse the stack and associate 32-bit words with addresses of variables, or functions, or offsets/lines within functions. Hard faults tend to be pretty gross in nature, knowing which line faulted, and the subroutine call immediately above it is usually sufficient to pin point the failure, or add some more guarding on parameters to catch the offending call that created the fault. ie testing for NULL pointers, or array index boundaries.