Peering into a microcontroller and seeing how the embedded software is executing has always been important to embedded software developers. In the good old days, developers used to have to instrument their hardware with extra outputs and use all kinds of tricks in order to take a stab at understanding what was happening with their system. In most cases it was simply guess work. Those good old days are thankfully gone and developers can now use tools such as Percepios’ Tracealyzer to peer into the microcontroller and understand exactly how the software is being executed and discover issues such as priority inversions, deadlocks and thread starvation to name just a few.
In this post, I’m going to walk the reader through how to setup the Tracealyzer tool using FreeRTOS running on a NXP K64F Freedom Board.
Step #1 – Download the Tools and Example
Getting a project and toolchain setup can sometimes be a time-consuming endeavor depending on the development board and supporting software that will be used. One easy way to get this example up and running is to download and install the following tools and also downloading a pre-built project that I put together. The tools that are used can be found below:
- Atollic TrueSTUDIO Lite (http://www.atollic.com)
- NXP Driver Suite 10.4 (Located here)
- MCUonEclipse FreeRTOS plugin (located here)
- Percepio Tracealyzer (located here)
- Beningo Example Project (located here)
Step #2 – Enable Tracealyzer in the FreeRTOS Plugin
Once the tools have been downloaded and installed. Developers can open the example project in the NXP Driver Suite. After opening the processor expert file and selecting the FreeRTOS component, developers will find the Percepio Trace tab as shown in Figure 1. The first step is to enable the Percepio Trace.
Figure 1 – Enabling Tracealyzer in FreeRTOS
Step #3 – Setup the Real-Time Trace Buffers
Configuring the buffers that will transmit event data from the microcontroller to the Tracealyzer tool is very straight forward. There are multiple modes that Tracealyzer can be configured to operate in such as Snap Shot or Streaming mode. Snap Shot mode can be used when a small amount of trace data is required that is triggered by an event that is of interest. To take an undefined length trace, using the Streaming mode is preferred. Example settings for configuring Streaming can be seen in Figure 2.
Figure 2 – Setting up the RTT Buffers
Step #4 – Compile the Project and Launch Tracealyzer
Once FreeRTOS has been configured in the Driver Suite software, developers can generate their project Processor Expert settings and then open the project in Atollic TrueStudio. The example is compiled in the ARM toolchain and then loaded onto the target board. Once the debug perspective is loaded, developers who have installed the Percepio plug-in will be able to launch the Tracealyzer from the Percepio menu as shown in Figure 3.
Figure 3 – Launch Tracealyzer through the TrueStudio Plugin
Step #5 – Configure the Streaming Trace Settings
In order to use the streaming trace, developers need to examine their debugger settings so that Tracealyzer knows how it is to receive the event data. This is done through the File->Settings menu. The tool need to know where that data will be coming from such as Seggers RTT, TCP/IP or USB. In this example, the settings are configured for the Segger RTT. Two up and down channels are configured to match the FreeRTOS settings as shown in Figure 4.
Figure 4 – Configure the Debugger Settings
Step #6 – Start Recording Data
Once the tools are configured and ready to execute, developers can start their debug session, begin executing code and also start recording trace data. When the Tracealyzer is successfully receiving trace data, it will report statistics on the trace session such as the total number of events and the event per second that are occurring. This can be seen in Figure 5.
Figure 5 – Recording Trace Data
Step # 7 – Analyze the Trace Data
Finally, after the microcontroller has ran it’s code for the desired time period, developers are ready to begin analyzing their trace data. There are many different views and reports that the trace tool can generate. The main view can be seen in Figure 6. In this view, developers can see the lifeline for the different tasks that are executing in the system. Developers can see when queue data is sent and received along with other RTOS objects such as mutexes and semaphores.
Developers can click on the task and get addition information such as the minimum, average and maximum execution times for the task. There is even information such as the response time for the task with minimum, average and maximum values. Developers can hide events that they are not interested in and switch views to see the CPU loading. In the past, developers could only guess and deduce this information let alone actually see it!
Figure 6 – Analyzing the Trace Data
Trace tools remove the guess work for developers who are working with real-time embedded systems. The days of guessing what a system is doing are over. Developers can now visualize and see the actual trace data for the how the system executed and dive into the details when strange behavior is present. Trace tools are an essential tool for developers to have on their workbench and we can expect that they will only become more powerful in the years to come.