Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

RTOS debug with STM32CubeIDE

mattias norlander
ST Employee

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!

Principal III

Hi Mattias,

I highly appreciate your tools and efforts and use them when I need. IMHO tracing is an important debugging feature as you see "how it came". Stack unwinding comes more into play for post-mortem analysis (fault analysis, stack usage, unwanted locking, etc..). So I revived an ancient tracing tool and ported it to FreeRTOS for STM32: It is work in progress as I let mostly my students work on it.


Chris F
Associate II

Dear Matthias,

first of all, thanks for the great debug capabilities for FreeRTOS in CubeIDE, I'm using them on a daily basis.

The only issue I have is with the "Stack Usage" and "Run Time" reporting in the "FreeRTOS Task List" tab which never shows any information:


Is this some configuration issue with FreeRTOS or are these features not implemented yet?


  • CubeIDE 1.8.0 on Windows
  • FreeRTOS V10.0.1 (with some patches for SEGGER SysView)

Best regards,


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

Bob S

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.

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.

Thanks for the input.

Indeed, I have forgotten to implement the function to return the runTimeCounter. Now the run time statistics are displayed as expected.

Also didn't know that the stack usage is only displayed if the view is toggled in the FreeRTOS Task List tab - also works as expected.

All nicely explained in the manual, should have RTFM before πŸ˜‰

Best regards,


Been there, been bitten by that.

Would be nice if there was a small section devoted to the "options"


Thanks - good points!

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

Associate II


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