Running function stack trace

[Lyu.1]

Hi,Master:

Question：

When the finished product cannot be debugged with jlink, I want to save and trace the function stack information through the firmware. When there are some accidental exceptions, I need to use the function stack to more delicately locate the problem.

My way of implementation:

foo_1 ()
{
    FUNC_TRACK_PUSH (foo_1);    // Push the function address into the stack structure
 
    ...// dosome thing
 
    FUNC_TRACK_POP (foo_1);     // Pop this function address from the stack structure
}
 
foo_2 ()
{
    FUNC_TRACK_PUSH (foo_2);    
 
    ...// dosome thing
 
    FUNC_TRACK_POP (foo_2);     
}
 
.
.
.
 
foo_x ()
{
    FUNC_TRACK_PUSH (foo_x);    
 
    ...// dosome thing
 
    FUNC_TRACK_POP (foo_x);     
}

Disadvantages:

This FUNC_TRACK_PUSH / FUNC_TRACK_POP macro must be added to the entrance and exit of all functions to record the current function stack call, which is cumbersome and inelegant.Is there another more beautiful way to achieve it?

Forgive me for poor English. Thank you!

regards

[CNava.1]

Hi Lyu,

I have the same question as your post. How to do a stack trace with just the stack dump available. Did you ever get an answer to your problem?

Thanks,

Carlos

[Tesla DeLorean]

The elegant way might be to write a script or pre/post-link step. Some tools allow for prologue/epilogue code to be added, or stack check functions to be called.

Personally, I've just used a Hard Fault handler that outputs a lot of registers, the instruction stream at/around the fault, and a reasonable portion of the stack.

Asserts or Error Handler reporting __FILE__ __LINE__ might be a way to identify critical points or sanity check, along with the ability to enable various levels of verbose telemetry.

The worst thing a product in the field can do is die silently in a while(1), as it gives support staff no ability to diagnose or understand internal failure modes, or differentiate them.

[CNava.1]

Thanks for the quick response Tesla,

I did implement all the fault handlers and now I do have a stackdumps available for all my FreeRTOS tasks. I also saved all relevant mcu control registers. I coded a diagnose utiltity that provides a post-crash diagnosis. All this is useful, but my development team would like to be able to backtrace into whatever task is responsible for the crash. I'm using the STM32L562xx mcu. Its an STM32 ARM Cortex-M33 variant. There is an interesting option for a Micro Trace Buffer on the M33 which provides exactly what I need, but it's an option and unfortunately my mcu does not have it incuded. I thiink I am left with trying to use the STM32 library code for unwind.h. There is a stackoverflow.com thread that provides a starting point. I have also seen some indications that I will need to add gcc compiler options to make the backtracing effective. It all seems like it's a common enough problem to warrant an STM32 app note or other reference, and that is why I'm searching the STM32 community for direction. I'm at the point of deciding which path to take, I just need a clear enough view to gauge whether I'm heading for a good solution, or off the rails into a dead end.

Thanks for listening,

Carlos

[S.Ma]

When you want a snapshot of the chip in an exception or code point, maybe try to dump the stack area, the core and peripheral register values, and any global variables needed, say in a wired I2C eeprom. Then move this eeprom to a nucleo, and make a code that restores saved register and memory, in debugger mode. Call stack should appear as the elf information is present (the code dump/undump) should be in the code. Maybe some toolchain can do better, here just trying with basic features.

[Lyu.1]

no，I haven't found a suitable method yet