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?

[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

[fronders]

Yes, you are right, but this whole forum thread​ has been dedicated ONLY to thread-aware debugging in a sense that you need to simultaneously view stacks of all threads, that's why your post might confuse newcomers. Information in the posts above is still relevant, problem is not solved by updating to 1.5.0+ (which a newcomer might think from your original message)