Over the last several posts, we have been examining how to use the ETM to retrieve trace information that can be used to debug and verify application behavior. The fact is, the ETM is only available on the Arm Cortex-M4 parts. The Cortex-M0+ parts do not support ETM. How can a developer trace their application code then? Developers can use the trace facilities that are built into ThreadX to record important application events and then use Percepio Tracealyzer to review and analyze the data.

Before a developer can analyze trace data, they must first enable the trace capabilities within ThreadX. By default, ThreadX is not configured with trace enabled. In order to enable trace, a developer needs to add the ThreadX source to the project and then enable the trace functionality. Once trace is enabled, the entire project needs to be rebuilt which will also rebuild the entire ThreadX source code. To learn more about how to do this, consider reading “Transitioning to ThreadX: Customizing ThreadX”.

When tracing is enabled within ThreadX, event data such as:

  • A thread starting execution
  • A thread stopping execution
  • A thread being deferred
  • A semaphore being given
  • A semaphore being taken
  • Etc.

are stored in a trace RAM buffer. This buffer can be configured for single shot mode, where once the buffer fills up the trace recording stops, or streaming mode, where the trace data is continuously streamed from the system. In either case, the SWD interface on the debugger is used to transfer the recorded trace data to the host PC. As a developer can easily imagine, the faster the debugging probe, the more event data that can be transferred and acquired.

Once the trace data has been recorded to the host PC, a developer can use Tracealyzer to open the recorded trace. The default view shows the task life lines in the vertical direction with task priorities starting with the lowest on the left with increasing priority to the right. By clicking on different task activities, developers can get statistical information such as:

  • Minimum, average and maximum task execution times
  • Minimum, average and maximum task response times
  • The number of times the task occurs in the trace
  • The task CPU utilization

An example visualization can be seen in the image below:


In this image, a developer can see the task life lines along with RTOS objects. The hashed task life lines show that the task was ready to execute but did not have a high enough priority to get access to the CPU. The solid task lines show that task was executing on the CPU. To the right, developers can see custom user messages such [Sensor3] along with queues and semaphores being used within the application.

This has only been a quick glimpse at the power that trace visualization can hold for developers. In the next post, we will look into more visualizations that can be very useful for a developer to debug and verify their application.  

Until next time,

Live long and profit!


Hot Tip of the Week: To learn a little bit more about Tracealyzer, check-out these two videos which cover fundamental Tracealyzer concepts: 

  • Trace Visualization(3:08) A walk-trough of the visualization in the main (vertical) trace view, what is displayed and how.
  • Navigation and Search(2:20) Explains the basic operation of the main (vertical) trace view, including zooming, scrolling and searching for relevant events.

 You may also find the Tracealyzer Getting Started page worth bookmarking and using as a reference.