RTOS debug with STM32CubeIDE

[mattias norlander]

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!

[SBACO]

Oh great !! thanks a lot for this "fix". I have read a lot about that and did not find this configuration anyware. Nevertheless, this is great that it is working now.

[ArnoutDekimo]

Man, this is so tucked away. 

I spent quite some time trying to get freertos thread aware debugging to work - in my opinion a vital asset for debugging, which comes out of the box with other vendors like ESP.

I initially assumed that the "freertos task list" was about all the out-of-the-box thread are debugging STM offered. I am evaluating an STM32U5 chip, and was initially trying to get openOCD to correctly report threads by modifying C:\ST\STM32CubeIDE_1.13.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_2.1.0.202306221132\resources\openocd\st_scripts\target\stm32x5x_common.cfg

by adding -rtos FreeRTOS to it.

Even though that showed the tasks in the debug view

it did not do correctly the stack unwinding.

Eventually I bumped into the RTOS proxy feature. This did not work with the openOCD configuration - it just exists immediately without saying much more. When I chose the stlink gdb server, I initally wrongly chose the wrong PORT (ARM_CM33 instead of ARM_CM3_NTZ), which then makes the proxy report "cannot read registers".

When finally choosing the NTZ settings, It goes do the full stack unwinding!

Again, this is such an important feature, and nevertheless it is so hard to info about the feature.

Anyway, many thanks for providing it!

[ArnoutDekimo]

And to come back to the question regarding feedback - as mentionned, there is probably something crashing when using openOCD. But it's not at all trivial to figure out what is going on / where to fetch the relevant logs, etc. Eventually, a dev just wants to have a working environment asap. If there are workarounds, (like using the ST link), I'll just go with that.

Anyway, what would definitely have been interesting for this feature, is to have more than just this devpost as "advertising". Like having some youtube video's showing off the functionality hits the google searches much faster, and, shows that it "should work". After that's clear, people might be more inclined to report bugs about it.

To be honest, the first through I had when seeing "rtos proxy", is that it requires some other hardware/software that was not part of STM32. I am pleasantly suprised it does some with it. 

[ArnoutDekimo]

And lastly (I cannot edit my posts, so I'll just create new ones), what would really be interesting, is to show the design of the rtosproxy somewhere in some documents. Perhaps making the blackbox binary instead of doing the work in openOCD and using the -rtos option there made sense in order to avoid others from using your work for other MCU's. Fine, no problem, but explaining this in a simple diagram, showing the communication interfaces between the processes (you undoubtably have that documentation internally) somehwere in a userguide would make it alot more accessible to devs. (anyway, just some feedback, since you guys asked:)

[Garnett.Robert]

Hi Mattias,

I have used this feature and appreciate your efforts.

I think that as users we miss the introduction of new features because we are too focused on the immediate problems and don't look at release notes etc. so when the new features appear we aren't aware of them.  I only noticed the addition of the FreeRTOS stuff in the project properties debug screen when I started a new project.

I use FreeRTOS in nearly all my projects except for the really tiny processors with small memories.

The support from Richard B and his off-sider is excellent, the documentation is good and it's easy to use. Being able to poke around in the source code is also very handy as you can learn how to do things.  I use ST Arm processors for all my projects and an very happy with them.

Best regards

Rob

[jcmoreau]

Is it possible to invoke the RTOS proxy from a terminal so that I can use it with VSCode? I am using STLink server with VSCode currently.