RTOS debug with STM32CubeIDE

ST Employee

Ok @Chris F, thanks for feedback! Nice it seems we have 2 users using these features now... ;)

The Stack usage and the Run Time views require building FreeRTOS with some extra defines and setting up a timer.

You can read about this in CubeIDE User Guide in the FreeRTOS section 6.2. Have a look at 6.2.1 Requirements. FreeRTOS 10.0.1 is from around 2018. I think it should support that feature, but not 100% sure.

Kind regards, Mattias

Graduate

This is correct. You need to enable stack reporting and likely stack checking (I do these by default). To get runtime, you need to enable a faster timer, say about 100 us to perhaps 10 us (your choice), and look at uxHighFrequencyTicks as a variable. Digging through the documentation about each particular feature on the FreeRTOS website will give you examples. These features are NOT automatically enabled. The other thing to note is that Runtime and the like cannot be used with optimization other than O0. You can either take care of this by setting the entire C compiler to O0, or just tasks.c to O0. Setting everything to O0 makes debugging easier at the expense of larger flash size.

B

Bob S

Super User

Hi Mattias,

Good to have these features. I didn't realize they weren't always there. For comments below, this is CubeIDE v1.7.0, HAL F7 v1.16.1, and CubeMX v6.3.0, running on a NUCLEO-F756 with either the stock ST-LinkV2 firmware or the "JLink-on-ST" firmware.

(1) Showing all kernel objects only shows objects that have names. There is an oversight/bug with showing queues, mutexes and semaphores. For example, in Middlewares/Third_Party/FreeRTOS/Source/queues.c, the list of queues (which also stores mutexes and semaphores) is stored in an array of structures. The structure stores a handle and a "const char *" pointer to the name. vQueueAddToRegistry() uses "name == NULL" as an indicator that the array entry is empty.

LwIP creates its mutexes and mailboxes without names. For example, in Middlewares/Third_Party/LwIP/system/OS/sys_arch.c the 3rd param to MessageQueueNew() is NULL, meaning no "attributes" structure (and thus no name). So calling vQueueAddToRegistry() multiple times with the name as NULL will overwrite the same array entry each time. And, since "name == NULL" indicates an empty entry, even the last call to vQueueAddToRegistry() with name == NULL will be ignored and not displayed in the IDE. As a result, none of the LwIP mutexes/semaphores/queues show up in the debugger RTOS window.

I had to modify the LwIP sys_arch.c to add names to each mutex/mailbox/semaphore so they would show up. And even this was a kludge that named them all the same name, since the vQueueAddToRegistry() only stores a POINTER to the name, it doesn't copy the name into local storage. So unlike task names, queue and mutex names must be "const" (static in RAM or stored in FLASH). This is OK for queues/mutexes created by CubeMX that have a global (and thus static) attributes structure. But not for objects created "on the fly".

(2) I have some instances where the "per task" callback stack lists in the left-side debug window only shows the current task (without the task name displayed). I haven't been able to narrow down why or when this happens. Some times this behavior continues after exiting debug mode and re-entering (i.e. re-starting a debug session). For a while I thought it might be due to some memory corruption related to a bug in my code, but having this issue persist across debug sessions kind of rules that out. Start a debugging session, program loads and runs to main(). Callback stack shows single stack trace as expected. Run code for a short while (long enough for FreeRTOS to init and Ethernet to start running), then pause (or hit a breakpoint). Most of the time I see all the tasks and their stacks. But sometimes only the single un-named task. And sometimes the system has to run for a longer time before I see only the single un-named task. And sometimes it always works. There is no pattern that I can discern, yet. If I can narrow this down, I will post details.

ST Employee

Thanks - good points!

I will check these points internally with colleagues in charge of the FreeRTOS / LwIP software components.

marbel

Visitor II

Hi

First off all thanks for the updated features.

The possibility to see what the other tasks are up to is a huge improvement

I would like so see either some reduced clutter or perhaps some better explanation of the added call stack data

Here i have restarted my application a couple of times and every time I do it it gets me a an updated number for the task. Cant this number be reset when the debugsession is reset?

Furthermore, I do not understand the number 536955008. Is it suppose to identify the specific task if i have more than one task started of that type?

If a task is blocked on a queue and that queue is registered in the queue registry, can you display that queue name in the call stack?

Best regards

Martin

N

NRedd.2

Graduate II

Hi @mattias norlander ,

I have a question regarding Azure RTOS debugging.

I have enabled RTOS proxy and TX_ENABLE_STACK_CHECKING

but I can't see the stack usage in STM32CubeIDE. It is displayed as N/A.

How can I get this information displayed?

Graduate

Oh, and look at the little icons in the upper right. One of them, looks like 3 horizontal bars, says enable stack checking. I think it's on the Azure view as well. Make sure that's checked/enabled.

Graduate

With regard to the original post:

It seems that your enhanced tools only work for Azure. If you have an extensive program with FreeRTOS, then switching to a Microsoft product involves a bit of work. Personally, I'm not all that happy with Microsoft, so another thing to consider.

I've enabled the freeRTOS proxy, and that seems to have done nothing, although I see unsatisfied calls looking for ThreadX.....

While it would be good to have the same kind of timeline information for FreeRTOS as is in Azure, I cannot afford the Percepio product, and don't have a Segger JLINK. Therefore I'm about half way through writing the equivalent using the FreeRTOS hooks.

Now, to the lack of feedback:

1) you didn't announce any of this in the release notes, AFAIK.

2) Had I not replied to a post in this thread, I wouldn't have gotten a notification.

3) Had I not looked at a reply and then gone further up the thread, I wouldn't have seen the original post, having replied just to a post on the thread.

I'd have liked to have known about this much earlier, but the way that the forum works, and the lack (I suspect) of a category for FreeRTOS that I can check, well....

That may be a problem where I just don't know where to look.

I do make extensive use of FreeRTOS, running it in expanded memory (QSPI) on the STM32L562VETQ processor. Programming is in C++ calling HAL routines as needed, so the project is reasonably involved.

So please devote some time to the FreeRTOS tools, as well as Azure, but I'd like to see more FreeRTOS tools myself.

I understand why the tracing tools are set for offline observation, it's easier that way. You could collect data either by SWV, Serial console, or writing to a buffer (I have one, so saving data to it, and then writing that to a file will work).

Be nice to have this working for FreeRTOS, though, as part of CubeIDE.

ST Employee

Hi Harvey,

I think there might be some misunderstandings here but for sure also some useful feedback that will be taken into account.

"I've enabled the freeRTOS proxy, and that seems to have done nothing, although I see unsatisfied calls looking for ThreadX....."

Not sure I understand what you did?

Enabling the proxy should give you the call stack of each thread in the "Debug" view (for FreeRTOS or ThreadX).
The RTOS proxy does not have anything to do with the "FreeRTOS Task list view or any other dedicated "FreeRTOS *" or or "ThreadX *" view.

"I'd have liked to have known about this much earlier, but the way that the forum works, and the lack (I suspect) of a category for FreeRTOS that I can check, well...."

It was communicated in the release post and release note in 1.7.0. Maybe we generally lack a "dev to dev" communication channel...? Feel free to suggest better working approaches if another online community is seen as best-in-class.

There are categories for FreeRTOS and AzureRTOS.

"You could collect data either by SWV, Serial console, or writing to a buffer (I have one, so saving data to it, and then writing that to a file will work)."

"So please devote some time to the FreeRTOS tools, as well as Azure, but I'd like to see more FreeRTOS tools myself."

Thanks. Understood, to be considered in the overall roadmap!

Kind regards, Mattias

Graduate

I see that I have not understood what's going on as well as I would like:

First:

"I've enabled the freeRTOS proxy, and that seems to have done nothing, although I see unsatisfied calls looking for ThreadX....."

Not sure I understand what you did?

Enabling the proxy should give you the call stack of each thread in the "Debug" view (for FreeRTOS or ThreadX).
The RTOS proxy does not have anything to do with the "FreeRTOS Task list view or any other dedicated "FreeRTOS *" or or "ThreadX *" view.

I missed the little line down from enabling the FreeRTOS proxy that allowed me to select which RTOS to use. It makes a difference, of course. Now that I see where you put the data and what it is, that's working well.

Second:

"I'd have liked to have known about this much earlier, but the way that the forum works, and the lack (I suspect) of a category for FreeRTOS that I can check, well...."

It was communicated in the release post and release note in 1.7.0. Maybe we generally lack a "dev to dev" communication channel...? Feel free to suggest better working approaches if another online community is seen as best-in-class.

There are categories for FreeRTOS and AzureRTOS.

I see them now, but didn't consider them as a separate searchable category. They kinda snuck up on be. Glad to see that they exist, I'll be monitoring them.

Suggestion:

it might be here and I haven't noticed it, but the idea of a release category organized by release number may be a little more obvious. That and sticky posts on the RTOS and FreeRTOS with pointers to useful features in CubeIDE. Having the release notes in a searchable form on the forum could be useful.

Note: would be nice on a page of forum posts to be able to navigate to the next group on both the top and bottom of the page.

With the increased use of any RTOS, the availability of good tools becomes more and more important. Glad that you're devoting time to this.

Thanks.

N

NRedd.2

Graduate II

Thank you @mattias norlander and @Harvey White! I am able to check the stack usage now!

S

SBACO

Visitor II

Hello,

This feature looks great ! but not able to make it work properly. I am using CubeIDE 1.10 and FreeRTOS 10. I can see the threads in the FreeRtos Task list view, but the debug view still show me only one thread. I am using ST Link with gdb server configuration, with RTOS proxy enable for freeRTOS for my CM7 STM32H750.

Probably related, but here is the console logs I have :

STMicroelectronics RTOS Proxy. Version 0.11.0
Copyright (c) 2022, STMicroelectronics. All rights reserved.
 
Loading RTOS driver... FreeRTOS
Connecting to GDB server 127.0.0.1 on port 61234 ... Connected
Listen for GDB connection on port: 60000 ... Connected
xList.pxNext.pvOwner == 0x0
Update threads. Failed collecting threads.
xList.pxNext.pvOwner == 0x0
Update threads. Failed collecting threads.

I try to google that, but nothing pops up. Hope you can help me figure this out.

I have disable the live expression as it seems there is a known bug with it. And I also try disabling the SWV as I have read also that it may link to problems.

Regards

S

Semer CHERNI

ST Employee

Hello @SBACO

The only known issue is that “configUSE_PORT_OPTIMISED_TASK_SELECTION�? must be set to 0 in the “FreeRTOSConfig.h�?.

You can start by doing this check.

Also, this problem can appear if there is a mismatch between the “ELF�? being debugged and the application running on the device.

Finally, the best approach to further analyze this behavior is, if possible, you provide a minimal project in which the issue appears.

Kind regards,

Semer.