RTC Magazine

Getting code to run requires programming skill. Making sure that it runs correctly requires that it be exercised and debugged. Assuring that it runs efficiently, optimally, reliably and safely requires in-depth analysis. The tools to achieve these latter goals start from the concepts of debugging but are used to examine code from myriad different aspects. However, for embedded projects that must work and on which human life and safety often depend, they are not an option.

When applying analysis to running code, the developer is very often confronted with a kind of “Heisenberg dilemma.” That is, “What level of intrusiveness into the actual execution can I tolerate and still be confident that what I’m seeing is what will actually happen in the deployed system?” That question applies mostly to timing issues. Among the other issues are assessing the overall performance, making sure that memory is being used efficiently and reliably and finding intermittent glitches that may not always show up in a standard debugging session.

In addition to the level of intrusiveness, one must also consider the specificity of the tool. Generally speaking, and of necessity, the deeper a tool delves into the inner workings of a system, the more intrusive it tends to become as well as more specific to the underlying operating system. There was a time when a certain tool loaded instrumentation tags into the source code, which then produced instructions that shot analysis data off to a connected development host or some attached probe. That has since largely fallen out of favor—at least for embedded development, although a certain amount of instrumentation may be needed in some cases.

Generally, however, the overhead on the target is caused by a relatively non-intrusive monitor or interface that buffers and sends execution data to the host. The least intrusive and deepest analysis is possible using tools that have a hardware assist, such as a JTAG probe, and take advantage of on-chip debug facilities such as the Traceports or embedded trace macrocells (EMTs). When not relying on instrumentation, a tool must be able to reproduce the timing characteristics as they would be without the overhead introduced by the tool.

Thus, when running a profiler, for example, the code may run slower overall than the deployed system, but the results displayed must reflect the actual execution times of the various functions. Most profilers can generate accurate results whether the code is running on the target or under an instruction set simulator on the host. In the latter case, it certainly runs slower, but is able to get an accurate instruction count and deliver performance measurements that can be used to identify areas that may be bottlenecks. It is these routines that the developer will want to zero in on to try to make more efficient.

A rich set of analysis tools, known as ScopeTools is available from both Wind River Systems and from Real-Time Innovations. Targeted at Wind River platforms using the Tornado development environment, the suite consists of five tools that are representative of the kinds of analysis tasks that need to be done for quality embedded software. They examine the code and its behavior from different aspects.

StethoScope is a tool that can monitor a running system and watch a set of variables, of any memory location. It lets you trigger data collection on specific events, change variables in a running program, see peak values and save all the data to disk. The purpose of StethoScope is to provide live data analysis on a running system without interfering with the code.

ProfileScope, on the other hand, is used to diagnose the execution speed of a program on a function-by-function basis. The profiler produces histograms of the execution times of the various routines so that you can zoom in on those that represent bottlenecks and concentrate on the areas that appear to be taking the most CPU resources in an effort to improve the overall performance of the application (Figure 1).

MemScope is a visual memory analysis tool that helps to efficiently manage memory use by identifying memory leaks as they occur and to check memory consistency and find errors that may occur in the memory pool. It offers Aggregate, Tree, Time and Fragmentation views and can track the allocation and deallocation of memory. This includes a view of the full stack of allocation to help figure out why memory was allocated. The tool can be used with a running system with no need for instrumentation using special compilations.