RTOS debug with STM32CubeIDE

mattias norlander · ‎2021-11-29

Hi Community,

Today you will provide the answers, and I will ask the questions!

Looking at the statistics gathered by our tools (assuming customer consent given), we can see the huge popularity of designing software relying on an RTOS. FreeRTOS is widely used, and we assume that the adoption Azure ThreadX will also spread quickly.

As CubeIDE tools guys, we have invested some effort in RTOS debug features. To quickly summarize the RTOS debug offer, let's make a list:

Window > Show > View > Other > FreeRTOS / ThreadX
- Provides views to visualize kernel objects for the 2 RTOSes
Debug config > Debugger > Enable RTOS Proxy
- Will allow the debugger to unwind and display the full call stack for ALL threads in the RTOS, not only the one currently in context!
For Azure ThreadX CubeIDE 1.8.0 can also conveniently export trace logs to be visualized "offline" in Microsoft TraceX tool

In our view the RTOS support is now quite decent! 😉

What is puzzling is the lack of feedback and bug reports on these tools.

We don't want to invest time in features which very few customer need or care about!

Please use this thread to share your thoughts/feedback/experience with us!

NRedd.2 · ‎2022-07-02

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?

Harvey White · ‎2022-07-02

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.

Harvey White · ‎2022-07-02

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.

mattias norlander · ‎2022-07-03

Yes, check Harvery's comment. The little button with horizonal lines can be toggled on/off. The reason is that performing the "stack usage" check can take some time since we potentially have to read a lot of memory. This can impact the responsiveness when single-stepping. Rather not always have that feature impact stepping.

See the User Guide for more details on this.

mattias norlander · ‎2022-07-03

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

NRedd.2 · ‎2022-07-04

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

Harvey White · ‎2022-07-04

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.

SBACO · ‎2022-11-14

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

Semer CHERNI · ‎2022-11-17

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.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

mattias norlander · ‎2022-12-01

@SBACO

Does setting the configUSE_PORT_OPTIMISED_TASK_SELECTION to 0 solve the issue?

Kind regards, Mattias