on
2021-09-30
9:43 AM
- edited on
2025-08-01
6:35 AM
by
Laurids_PETERSE
To add TraceX support to a STM32CubeIDE project and properly use it you’ll need to follow a few steps, described in detail in this article.
Goal: Add TraceX support to STM32CubeIDE using X-CUBE-AZRTOS-H7
Although the example is using the NUCLEO-H723ZG, you can use the same steps for other STM32H7 based boards. The main differences are usually pinout and clock configuration.
This article will show you how to add TraceX support in a simple project that already uses ThreadX with the X-CUBE-AZRTOS-H7 software package.
TraceX allows a post mortem analysis of the thread sequence that occurred during firmware execution; here is a simplified block diagram flow:
This works perfectly if I use only ThreadX module, but when I tried to use TraceX in the application where ThreadX and USBx are used I receive always a "Precise data access violation" hard fault. As I figured out, it happens when USBx thread (registered in a separate byte pool than ThreadX threads) tries to register a traceX object (in _ux_trace_object_register function).
Can you, pls, give an example of how to set up a TraceX functionality for ThreadX used with USBx as well as other Azure modules?
p.s. I have tried this on Nucleo-L552.
Hello @QDot ,
Thank you for your feedback, we are working on an article covering TraceX and USBX and ThreadX that would be of interest for you.
Do you have similar settings for when we have ThreadX on Secure - Non Secure projects?
Like for e.g., for STM32N6
While loading for debugging from the FSBL, with debug load set for FSBL + Sec + Non Sec, the error I get is
Error in final launch sequence:
Failed to execute MI command:
target remote localhost:60000
Error message from debugger back end:
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
Failed to execute MI command:
target remote localhost:60000
Error message from debugger back end:
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Shutting down...
Exit.
This goes away when I untick "RTOS Kernel Awareness" => "Enable RTOS Proxy" - From the debugger tab