Debug FreeRTOS with STlink GDB

[rlk1]

I am trying to debug an application running on a Nucleo-F411RE using the VS code STM32 extensions. I am using the onboard debugger with the "STM32Cube: Launch ST-Link GDB Server" debug launch option.

The RTOS proxy is starting, but I get the following errors when it hits the initial break at main.

RTOS proxy: Missing symbol: xQueueRegistry.

Missing symbol: xQueueRegistry.

Missing symbol: pxCurrentTimerList.

{"label":"","value":[{"label":"Version","value":"1.0.0"},{"label":"Driver","value":"freeRTOS"},{"label":"Kernel state","value":"Not started"},{"label":"Data","value":[{"label":"Tasks","value":""}]}]}

Attempt to use a type name as an expression.

Attempting to continue, when it hits my first breakpoint I get:

Breakpoint 2, SPITestTask (pars=0x0) at D:/Users/kecknew/Documents/BowieStage/TMC5041Src/spitest.cpp:16

16 spi.SPISetup(&hspi2);

monitor rtos -m state

Wrapping read detected. Addr: 0xffffffff; Length: 256

Ignoring packet error, continuing...

Where the last line keeps repeating and the debugger becomes unresponsive.

Debug firmware on the board is: V2.J48.M35

Application is a basic FreeRTOS application as generated by CUBE MX with only one thread.

All tools were recently installed so should be up to date.

Debugging works fine if I do not use the RTOS server, but then I lose a lot of useful features.

Is this a bug or am I doing something wrong?

[LaurentL]

Hi rlk1,

The Missing symbol xQueueRegistry is not an issue. You need to add some code to initialise this variable.

But It isn’t mandatory to have it to debug.

 

The “Missing symbol: pxCurrentTimerList.” message is more problematic I suppose.

Did you set a Timer as Timebase source in STM32CubeMx, System Core => SYS in “Pinout & Configuration” panel ?

You need to change this as FreeRtos uses Systick.

 

Rgds,

Laurent

 

[rlk1]

Whether I use SysTick or a dedicated timer makes no difference.

I have found the following:

If I use Segger Ozone with a J-Link EDU, RTOS debugging works.

If I use the J-Link EDU with the VS Code STM plugins, RTOS debugging fails similarly to ST-Link. The first breakpoint at Main is OK, but if I continue, typically the debugger hangs, there may be some error messages or not, and often VS Code ends up hung. The problem appears to be that something is wrong with the GDB server and RTOS support provided with the STM VS Code plugins.

[rlk1]

After trying to debug with the Eclipse debugger and having exactly the same issue, it occurred to me that perhaps the old configUSE_PORT_OPTIMISED_TASK_SELECTION issue was the problem. It is. This is distinctly annoying because Cube MX forces the value to 1 and does not allow you to change it, at least for the STM32F411RE. This means that you have to hand edit FreeRTOSConfig.h to set it to 0 being careful that Cube MX is not going to be able to set it back again. It is also annoying that the documentation for FreeRTOS debugging with VS Code and the STM extensions does not warn about this (that I could find). It also seems that if Ozone can deal with configUSE_PORT_OPTIMISED_TASK_SELECTION=1 the STM software should be able to as well.