Using Segger SystemView utility

Article By : Jacob Beningo

Let's take a look at one tool, Segger SystemView, to see how developers can get started using advanced debugging techniques.

Microcontrollers are becoming exceptionally complex and feature-rich, so traditional debug techniques that have existed since the good old 8bit days just aren't efficient or insightful enough to handle the challenges developers now face. Trace analysis and debug tools are coming to market, though, that hold the potential to revolutionise the way that embedded systems are debugged. Let's take a look at one such tool—Segger SystemView – to see how developers can get started using advanced debugging techniques.
Every time I debug an embedded system I am always uneasy. There are so many assumptions that are being made as to how the code flows, how interrupts fire, and about code timing, to name a few. A single incorrect assumption can cause the debug cycle to drag on by masking the true root cause. I believe this is where the power of trace tools has the potential to change how we debug systems. Being able to peer into the system, generate time-stamps and event logs, and track task execution is very powerful. I no longer need to assume that my system is executing in a certain way; I can visually verify that it is. If my assumption is wrong, the evidence is right there in the trace and now I know my grief's source.
Advanced trace tools provide information in a visual form. When I'm teaching a course on real-time operating systems and discussing rate monotonic analysis, I often draw timing diagrams that demonstrate how tasks are time sliced and getting dedicated access to the CPU, show expected task completion times, and other useful design parameters. SystemView allows an embedded software developer to visually see how their software is executing in just such a manner. The SystemView window in the figure demonstrates exactly what a developer would see when they start the tool.

Figure: A visual representation of software execution from Segger SystemView.

The tool traces the application execution by recording entry and exit from functions, system events, interrupt occurrences, and other parameters that are interesting to a developer. The trace information can be downloaded from the system and analysed, for example to determine if an unexpected glitch is occurring or determine if a task is taking too long to execute. Depending on the microcontroller architecture, the trace data can be reviewed in a streaming real-time manner or downloaded in a single-shot recording.
Great debugging powers such as these doesn't come without some disadvantages. So far the biggest issue I have encountered is the time investment needed to get over the tool's learning curve. Segger's website has some great examples and instructions, but there is so much technology built into trace capability that wrapping one's mind around exactly how it works and how to set it up isn't trivial. I spent significant time reading the 154-page manual then setting up an embedded system and configuring it before I finally started to get trace data. Once I was through the learning curve, though, and had documented my own process, each use got easier and easier.
SystemView uses a technology known as Real Time Transfer (RTT) that must be installed on the embedded target. RTT is used to collect data on the target and store the data in a buffer. RTT then streams the data through debugger hardware to SystemView.
The documentation mentions that a typical implementation uses approximately 2 KB of flash space and 600B of RAM. My first setup attempt used a plugin for Processor Expert, which required an up and down buffer of 1024 to get the code to compile. Eventually I discarded the plugin and manually set up the interface. I was then able to achieve numbers much closer to those in the datasheet.
The great part about the SystemView tool is that it works with any Segger J-Link debugger and can even be used with a non-Segger debugger under certain conditions. The software is a free download and doesn't have any fees, licences, or royalties associated with it. There is even an API so that engineers can create their own tools that use the interface. If SystemView isn't to one's liking, alternative tools exist such as Percepios' Tracealyzer can also be used with the J-Link and RTT interface.
Using a trace tool will undoubtedly become standard practice at the development cycle's start. Embedded software developers can run their system overnight and gather a baseline trace on performance, timing, and other critical system metrics. Then they can use continuous testing, a great way to catch deviations from the baseline when they first occur rather than allowing issues to stack up until an obvious problem arises. Early discovery coupled with source control should easily identify problematic code and result in a quick fix rather than a convoluted, snail paced debug session.
In time, trace technology may become so seamless and automated that developers will no longer need to debug an embedded system. Computers will be able to automatically detect noncompliance and deviations and highlight the recently changed lines of code in the misbehaving task. The thought is a bit optimistic, but one can always hope.

About the author
Jacob Beningo is principal consultant at Beningo Engineering, an embedded software consulting company. Jacob has experience developing, reviewing and critiquing drivers, frameworks and application code for companies requiring robust and scalable firmware. Jacob is actively involved in improving the general understanding of embedded software development through workshops, webinars and blogging.