Thread awareness debugging in FreeRTOS [STM32CubeIDE 1.1.0 has a bug for using "-rtos FreeRTOS" on ST-LINK(OpenOCD)].

[KOkun.1048]

In STM32CubeIDE 1.0.2, after I added '-c "$_TARGETNAME configure -rtos FreeRTOS"' to 'OpenOCD Options', I could debug FreeRTOS's target with threading mode.

But, in STM32CubeIDE 1.1.0, even if I set same settings to 'OpenOCD Options', I could not debug with threading mode. In this version, openocd outputs 'Error: No symbols for FreeRTOS'.

Could you please check about this?

[egoltzman]

I checked this on CubeIDE 1.3.1 and it is working

[KOkun.1048]

Please add "-Wl,-undefined=uxTopUsedPriority" to your linker options.

[JBeca.1]

Hi,

I'm using STm32F446RE and I don't reach a valid configuration to debug with multi thread support. I'm using st cube ide 1.2.0

I followed the 6 steps defined by @KOkun.1048​ and I get error allocating threads. This is the error message:

Open On-Chip Debugger 0.10.0+dev-00022-g02bea1f (2020-01-08-09:31)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 8000 kHz
adapter_nsrst_delay: 100
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 8000 kHz
Info : STLINK v2.1 JTAG v35 API v2 M26 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.248915
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Stlink adapter speed set to 4000 kHz
Info : STM32F446RETx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800099c msp: 0x20020000
configuring PLL
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Stlink adapter speed set to 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
Info : device id = 0x10006421
Info : flash size = 512kbytes
Info : Padding image section 0 with 12 bytes
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20020000
Error: Error allocating memory for -184299509 threads
Error: Error allocating memory for -184299509 threads

Any idea?

Thanks for you support

Jordi

[Panometric]

Actually, I remember I used to always get "Error allocating memory for .. threads" but the thread aware debugger worked anyway.

Curiously, I am not seeing it now, but I do see: "Error: Error reading thread list item object in FreeRTOS thread list"

I think it;s because the initial trap is before the OS kernel is running, so you will not see threads. Set a breakpoint in a thread and run, you are probably fine.

I also use this for thread inspection, has stack checking. https://www.highintegritysystems.com/down-loads/stateviewer-plug-in/

[JBeca.1]

Hi @Panometric​ ,

thanks for the feedback.

It is true, I get the error "Error allocating memory for xx thread" but debugger runs and "works". My problem was that I disabled the option of "set breakpoint at: main". And it is necessary to put the task method name

So, now I can debug the application and see the differnt threads, but I say "works", because the first time the debugger stop to all tasks, but the next iteration only stop at on task (the first that debugger entered).

I know that it is strange, but... Any idea?

Regards

Jordi

[JBeca.1]

ok, I think I found the "solution".

I had enabled the optimization option "Os" (for size), and I changed to "Og" (for debug), and debugger stop to all breakpoints always.

Thanks for the support!

Jordi

[Boozo]

Using CubeMX 1.4.2 and an STM32H7 microcontroller.

For me '-c "$_TARGETNAME configure -rtos FreeRTOS" ' did not work. Got following error from OpenOCD:

Open On-Chip Debugger 0.10.0+dev-g30d1303 (2020-06-18-09:13)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
stm32h7x_cti_prepare_restart_one
can't read "_TARGETNAME": no such variable

Needed to replace it with '-c "$_CHIPNAME.cm7 configure -rtos FreeRTOS" '.

The problem here was that the _TARGETNAME variable is not defined in the 'target/stm32h7x.cfg' OpenOCD script file!

Happy debugging :rocket:

[PNowa.1]

Hi.

I'm using STM32CubeIde 1.4.2 for Mac OS. I've managed to configure FreeRTOS debugging on STM32F4 MCU but I can't get it working on STM32G071RBT. This is what I get in debug view:

It won't stop on any breakpoint. Does anybody managed to get FreeRTOS threads debugging on STM32G0? What can be the cause of this?

[OLiso]

I'm working with STM32H743 and instead of

`-c "$_TARGETNAME configure -rtos FreeRTOS"`

I needed to write

`-c "$_CHIPNAME.cm7 configure -rtos FreeRTOS"`.

because `$_CHIPNAME.cm7` is used in config file (C:\STM32CubeIDE_1.5.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_1.5.0.202011091203\resources\openocd\st_scripts\targetstm32h7x.cfg).

Also, I needed to use the symbol `uxTopUsedPriority` in my code because in another case it was not compiled correctly.

In my case, I added `extern const int uxTopUsedPriority;` to my main.cpp and printed the value of `uxTopUsedPriority` (printf("uxTopUsedPriority = %d\r\n", uxTopUsedPriority)).

Map file before 'correct compilation':

 .data.uxTopUsedPriority
 0x0000000000000000 0x4 App/freertos_openocd_patch.o

Map file after 'correct compilation':

 .data.uxTopUsedPriority
 0x0000000024000008 0x4 App/freertos_openocd_patch.o
 0x0000000024000008 uxTopUsedPriority

I use STM32CubeIDE Version: 1.5.0 Build: 8698_20201117_1050 (UTC).

[Brian TIDAL]

Hi,

STM32CubeIDE version >= 1.5.0 has now the support for FreeRTOS™ thread-aware debugging.

See chapter 6 (RTOS-aware debugging) in STM32CubeIDE user guide UM2609

Rgds

BT

[fronders]

@KOkun.1048​ Thanks for your guide!!

@Brian TIDAL_O​ you're kidding right? The issue still exists in 1.6.1

  

For FreeRTOS only RTOS-aware viewers have been added (Task list, Timers, Queues and Semaphore) - while no thread-aware debugging has been introduced (when you can simultaneously view stacks of all threads).

 

Please don't desinform people.

While the hack above works only with OpenOCD w STLink, it does not support STLink GDB Server yet.

[Brian TIDAL]

HI @fronders​ 

One of the common definition of Thread aware debugging is : "Thread aware debugging specifies the capability of a debugger to show all existing threads / tasks of the RTOS, running on the embedded system when the target system is halted by the debugger." In that sense, STM32CubeIDE since version 1.5.0 has the support for FreeRTOS™ thread-aware debugging. The STM32CubeIDE user guide UM2609 gives comprehensive information about the various views and the way to use this feature.

I believe each developer has his own definition of what is thread-aware debugging  and has his own expectations about what thread-aware debugging should provide.

I am sorry that the current level of RTOS-aware debugging features integrated in STM32CubeIDE does not meet your expectations.

Rgds

BT