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 set up the Tracealyzer tool using FreeRTOS running on a NXP K64F Freedom Board.
Step #1 – Download the Tools and Example
Getting a project and toolchain set up 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 by also downloading a pre-built project that I put together. The tools that are used can be found below:
- Atollic TrueSTUDIO Lite (located here)
- 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 – Set up the Real-Time Trace Buffers
Configuring the buffers that will transmit event data from the microcontroller to the Tracealyzer tool is very straightforward. 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 needs 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 its 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 is 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.
Bootloader Design Techniques for Microcontrollers.
Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com/, and sign-up for his monthly Embedded Bytes Newsletter.