A typical developer, on average, spends around 40% of his or her time debugging software. This can lead to increased costs and time to market as developers grapple with system complexities and try to understand how various software components are interacting in their system. There are several tools that I use in my own development cycle that I have found to be indispensable. They help not just to understand the software, but also to decrease my costs and time to market. Let’s examine several of these tools:
Tool #1—A Trace-Enabled Debugger
The first tool that I consider critical to have in the toolbox is a trace-enabled debugger. Whether it’s an ARM Keil ULINKplus or a j-Trace, these tools provide a developer with the ability to access streaming trace capabilities and the memory on an embedded target. These high-end debuggers can be interfaced to several different visualization tools that can provide developers with insights into how their system is behaving. While the high-end tools may not always be necessary to use these visualization tools, I’ve found that their secondary features—such as unlimited break-points, spare GPIO pins, and even energy monitoring—can be indispensable.
Tool #2 – Micrium µC Probe
|(Image source: ARM Keil & SEGGER|
Micrium’s µC Probe can be used for real-time visualization of variables and data in an embedded application. Developers are able to custom build their own user interface that best suits their needs to monitor how their system is performing. I’m a newer user to Micrium µC Probe because I originally thought that it could only be used with the various versions of µC OS. I recently learned that µC Probe can be used on nearly any embedded system where the debugger is capable of simultaneously accessing the microcontroller's memory. This capability gives the tool the ability to read memory in a non-intrusive manner that contains nearly no overhead if a developer is using a J-Link or a j-Trace.
|(Image source: Micrium)|
Tool #3 – Percepio Tracealyzer
Over the past several years, I’ve grown quite fond of using Percepio Tracealyzer to trace an embedded application and visualize how it is behaving. Tracealyzer can be integrated into an RTOS-based application to record the events that are happening in the application, such as task context switches, interrupts, mutex locks and unlocks, along with many other events that occur. These events can be recorded in a single shot manner around a particular problem area in code or can be real-time streamed and viewed to a host computer. Once the trace has been recorded, a developer can then use more than 30 views to review the program execution, task and event timing, communication flow, and many other aspects of the application. I will typically use this tool to debug an application, but I will also use it to trace example code, software stacks, and other code that I want to understand.
|(Image source: Percepio)|
Tool #4 – SEGGER System View
SEGGER System View is another trace visualization tool that can be used to see what an application is doing. System View records RTOS events and displays a few useful pieces of information, such as the task timing, task execution visualization, and the CPU load. The tool contains just four views, but it’s enough to still get useful information about how the application is behaving, which is great for a free tool.
|(Image source: SEGGER)|
Tool #5 – SEGGER Ozone
Instruction tracing can be an important tool to embedded software developers who are interested in ensuring that their test cases get 100% coverage over their code base. A free tool developers can use in conjunction with the J-Trace is SEGGERs Ozone. Ozone allows developers to see how good their code coverage is while letting them monitor function execution and see every instruction that has been executed in the code. There are many details that developers can glean from their application using this tool.
|(Image source: SEGGER)|
Early in my career, I was always uneasy that I couldn’t see what was actually happening as my system executed its software. Sure, I could look at external behaviors and add a few instrumentation messages to verify the behavior to some extent. But I could never see everything. If you can’t see what the system is doing, it makes it difficult to debug and verify the software. If you can see what’s happening, developers can come to solutions far faster, which at the end of the day saves time and money. These applications are examples of tools that I use. There certainly could be others for different tool chains. I hope that you will investigate what tools fit within your own environment that provide these types of capabilities.
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.
Today's Insights. Tomorrow's Technologies.
ESC returns to Minneapolis, Oct. 31-Nov. 1, 2018, with a fresh, in-depth, two-day educational program designed specifically for the needs of today's embedded systems professionals. With four comprehensive tracks, new technical tutorials, and a host of top engineering talent on stage, you'll get the specialized training you need to create competitive embedded products. Get hands-on in the classroom and speak directly to the engineers and developers who can help you work faster, cheaper, and smarter. Click here to submit your registration inquiry today!