Freertos backtrace problem

[PKurz.1]

Hi,

STM32CubeIDE 2.0

fresh project

with

GNU Tool for STM32: 14.3.rel1 :

GNU Tool for STM32: 13.3.rel1

regards

[Souhaib MAZHOUD]

Hello @PKurz.1 

Could you please provide the name of the MCU, the FreeRTOS version, or attach your project for further investigation.

BR, Souhaib

[mattias norlander]

Hi @PKurz.1,

Spotted similar behavior in STM32CubeIDE for VS Code... Made me wonder what is the root-cause?! Then the team informed me about this thread from you. We are facing the same issue...

As you can see the stack unwinding is a bit broken... showing multiple entried of pxPortInitialiseStack.

Google is your best friend... Found this post on FreeRTOS forum:

• https://forums.freertos.org/t/gdb-stack-unfolding-in-cortex-m4f-port/2176

In a nutshell you can get a better (but not perfect behavior) by defining:

#define configTASK_RETURN_ADDRESS NULL

It seems that nobody have found the "perfect solution". I am not an expert on neither GCC/GDB nor FreeRTOS. Hence I took a pragmatic approach to try to find some work-arounds:

In STM32CubeIDE for VS Code I can easily switch different bundles that I want to use when compiling/debugging my project without hacking my environment. GDB and GCC is delivered as 2x different bundles. So I configured my FreeRTOS projects to build and debug the FreeRTOS application with these combinations of bundles:

• Test1: GCC-13 + GDB-13   =    OK
• Test2: GCC-13 + GDB-14   =    OK
• Test3: GCC-14 + GDB-13   =    FAIL
• Test4: GCC-14 + GDB-14   =    FAIL

It seems that GCC-14 is the common denominator in all casese where debug stack unwinding is "faling"?!

This seems to be an "up-stream" bug, should be solved "up-stream"...