7 Tips for Getting Started with Application Tracing

Early in my career it always bothered me that I couldn’t see how my program was executing. I would write some software, cross my fingers, and assume the application worked because the LED seemed to be blinking with the correct timing. In reality, once the run button was pressed, who knows if the application executed along the paths the way I thought they should. Verifying the application ran correctly required extraordinary effort.

Developers have not had to guess or hope for several years now. Modern microcontrollers have had the hardware built in and the debugging technology available for the past several years to

  • to visualize and see the program execution path;
  • monitor the exact instructions that are executed by the processor;
  • record events occurring in the application such as context switches;
  • track the program counter and stack pointer.

Tracing has provided developers with new insights, debugging, and verification capabilities that have the potential to dramatically change the way embedded software is developed. Here are seven tips for getting started with embedded application tracing.

 

Jacob Beningo, ESC, Embedded Systems Conference, tracing

 

Tip #1 – Purchase a High-End Debugger Probe

The tools required to do basic tracing don’t need to cost an arm and a leg. Tracing can be performed using low-cost debuggers but I have generally found that it requires more time and effort to get it up and running. Trade-offs need to be performed to get some data out. Low-cost debuggers tend to be slower and have smaller buffers, which means it may not be possible to download all the data fast enough.

Now this may sound like I’m advocating purchasing expensive tools but I have noticed that when I tried to go cheap, it costs me far more in time and effort than if I had just bit the bullet and purchased the professional tool. For example, when I started playing around with tracing, I used a debugger I had gotten for maybe $100 but spent days tweaking the target library buffers and code so that I could get a clean trace from it. Fast forward to when I invested in my J-Link Ultra Plus -- the adjustments to get tracing up and running were minor, I didn’t have to down select the data I wanted, and suddenly I had a third-party tool that worked with nearly any IDE so I don’t have to keep buying low-cost debuggers for every new microcontroller I work with.

Tip #2 – Download System Viewer and Tracealyzer

There are different tools that can be used to record trace data and then view that data, but the two tools that I like and have been using the most is Segger’s System Viewer and Percepio’s tracealyzer. These tools are very powerful and provide a wide range of trace functionality. System Viewer is free while Tracealyzer has a 30-day trial and a fee associated with it.

Tip #3 – Create a Simple Test Application

I wouldn’t recommend a developers’ first trace being with a full-fledged production intent application. These applications can be complicated, fast, event-heavy, and confusing. We don’t want to be overwhelmed with data before understanding how to sift through it. Start by making a custom, simple application. An application that blinks a few LEDs, accepts a user button press, and maybe has a UART received task. This application is simple enough and has user interactions that are easy to follow.

Tip #4 – Start with a One-Shot Acquisition

Don’t start out streaming a bunch of data and then trying to analyze it. Trace libraries and viewers will let the developer set up one-shot acquisitions that start on a trigger. Start by using the one-shot and acquiring data around a button press or the LED signal transition. Once you get comfortable identifying and navigating the trace, then you can try more advanced tracing.

Tip #5 – Review Statistical Analysis Reports

Trace viewing tools can provide a developer with insights they have never had before. For example, they can provide developers with statistical information on how the task code is executing. The data for each task can be analyzed to provide the percentage that the CPU is utilized, along with providing minimum, average, and maximum execution, periodicity and separation measurements. This information can help developers understand how their system is executing and whether it is consistently meeting the timing requirements that they expect.

 

Jacob Beningo, ESC, Embedded Systems Conference, tracing, application

 

Tip #6 – Slowly Increase Application Complexity

Once a developer has figured out how the trace tools work and have mastered their basic application, they can start to increase the application capability. Several ideas on application features that could be added and reviewed include:

  • locking and unlocking mutexes;
  • giving and taking semaphores;
  • passing data in message queues;
  • monitoring interrupt periods and execution times.

Slowly adding new features will help a developer get used to examining the trace and identifying events.

Tip #7 – Use Streaming Trace Carefully

More often than not, streaming event data is the way to acquire a trace. Streaming trace will constantly stream event data to a host PC. A developer can run their application through its test cases and then review the trace to verify behavior. Be warned, streaming trace for hours to days can record a lot of data and be very time consuming to sift through.

Conclusion

Tracing cannot just help developers understand what their application is doing but can also be used to verify and validate the application. Tracing can help prove that test cases are traversing every branch and even spot issues such as priority inversions. Tracing is an important tool that every developer should be utilizing to verify and debug their applications.

 

Join Jacob Beningo at ESC Minneapolis!
Join Jacob Beningo for three can't-miss sessions at ESC Minneapolis, Nov. 8-9, 2017. He will be on-hand live at the Minneapolis Convention Center, where he will be discussing: "Getting Started with Trustzone using Cortex-M Microcontrollers," "Transitioning to RTOS-Based Systems," and "Mastering Real-Time Debugging Techniques on the Cortex-M." Click here to register today!

 

 

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 jacob@beningo.com, at his website www.beningo.com/, and sign-up for his monthly Embedded Bytes Newsletter.

Post new comment

The content of this field is kept private and will not be shown publicly.
By submitting this form, you accept the Mollom privacy policy.