Tracealyzer for ThreadX


Tracealyzer for ThreadX is a sophisticated tool for tracing and visualization of ThreadX-based systems.

Tracealyzer gives an unprecedented insight into the runtime behavior, which speeds up debugging, validation and performance optimization. Issues that otherwise may require many hours, days or even weeks to solve, can with Tracealyzer be understood quickly. This saves you many hours of frustrating trial-and-error troubleshooting. With Tracealyzer you see what is really going on in your system!

"We are extremely excited and pleased about the Tracealyzer port to our Industrial Grade ThreadX RTOS. The combined best-in-class visualization assets of Percepio’s Tracealyzer and our industry leading ThreadX RTOS will greatly help embedded developers confidently get their IoT products to market quicker". - William E. Lamie, CEO Express Logic, Inc.

Tracealyzer provide state-of-the-art visualization developed since 2004, specifically designed for RTOS-based systems by the leading specialist in this area - Percepio AB, a company based in Sweden.

Tracealyzer actually understands the meaning of the RTOS events and performs advanced analyses to improve the visualization and simplify comprehension. This makes it much easier to draw conclusions from the data, understand the problem and verify the solution.

Tracealyzer provides more than 25 interconnected views of the runtime behavior, including the execution of tasks (threads), interrupts, interactions between threads, as well as User Events that you may log from your application code. Tracealyzer can be used side-by-side with a traditional debugger and complements the debugger view with a higher level perspective, ideal for understanding real-time issues where a classic debugger is not sufficient.

Tracealyzer does not require additional tracing hardware, which means that it can be used in deployed systems to capture rare errors which otherwise are hard to reproduce.

Using Tracealyzer

This section is intended to give a quick overview of the features and how this tool can be used. More detailed information on the various features are available in the later sections.

The main trace view provides all recorded information on a vertical time line, focusing on the execution of threads, interrupt handlers and kernel calls. This view is complemented by some 25 additional views providing high level overviews or focused views from different perspectives.

Kernel events such as calls to kernel services and User Events are displayed as text labels on the right side of the scheduling trace. The labels are color coded depending on the type and status of the operation (red for blocking, green for resume, yellow for user events etc.).

Additional Views

Below follows a few examples of other views and dialogs which complements the trace view. There are over 25 views in total. All views are connected to the main trace window or another relevant view, which allows you to switch perspectives without losing focus.

To locate a particular task or interrupt in the trace view, open the Finder (Shortcut Key "Ctrl-F"). In the Finder dialog, you can also specify filters on timing properties such as response time, in order to quickly find the extreme cases.

The Object History View allows you to track a particular kernel object, such as semaphores and mutexes. You see all operations on this object and how its' state changes as a result. Double clicking in this view highlights the event in the main trace view.

The CPU Load Graph displays the CPU usage per task and interrupt over time. This can be zoomed separately of the main trace view, and can also be used to navigate the trace view by double clicking in the graph.

Example Uses

Make sure to visit the Getting Started page with articles, tutorials and practical applications of Tracealyzer.

The general uses of Tracealyzer include:

  • Real-time debugging - Analyze the detailed execution of tasks and interrupts. Why did the system freeze? Why is there sometimes a "glitch" in the behavior?
  • Validation - Is the system executing the way you think it is? Are the tasks and interrupts executing when suitable? Are the task priorities suitable? Is there any undesired blocking or timeouts? How large does the message queues need to be?
  • Profiling - Study the CPU load over time and find hot-spots where tasks are delayed and optimization is relevant. How much processor time and memory is allocated by the different tasks? How is 3rd-party components such as TCP/IP stacks and File Systems behaving? Are there any memory leaks?
  • Application behavior - User Events allows you to log and visualize any event or data from your application code, such as inputs, state transitions or other any variable of interest. User Events are stored in a matter or microseconds, which allows for using them also in time-critical code.

Tracealyzer gives you better possibilities for finding out what is really going on in your system. For instance, if a task never gets to execute you can see why this is the case. Perhaps higher priority tasks are using all CPU time, so that the scheduler never lets the lower priority tasks execute. This is revealed by the CPU Load Graph.

Another reason for a "missing task" might be that the triggering message/semaphore signal is never sent, or sent to the wrong destination, or that the timeout is too short so that the send fails. The Communication Flow graph shows an overview of task interactions. The Finder can be used to find individual events, e.g., a message sent from a particular task to a particular message queue, and has a filter which can be used to quickly find operations which failed due to timeouts.

If the system performance is too slow, or if you simply want to measure the performance, you can study the Statistics Report for a overview of performance metrics like task response times and average CPU usage. Moreover, the Actor Instance Graph reveals the instances with high executions time and/or high response times.

All views are interconnected in clever ways, allowing you to navigate between views with ease and see the data from different perspectives. For instance, if you find a high response time in the Actor Instance Graph, you can simply click on the data point to focus the main Trace View on this point and see the cause - it could be that the actual execution time of the task is unusually long, but could also be caused by interference from other tasks or interrupts. This allows you to focus your optimization efforts on the true cause, which can save you a lot of time.

Copyright Percepio AB 2017, all rights reserved.