Choosing the right embedded software debug environment

BY LARRY RITTER
Applied Microsystems Corp.
Redmond, WA

The nature of embedded development requires that most debugging be performed
in-target. Only in the target environment are the interactions, stimulus, and
control elements all present.

Several tool choices are available for in-target debugging. The developer must
consider their differences, and then select the one that best matches project
objectives and level of complexity.

This article examines the advantages and disadvantages of six of the most
prevalent code debug tool categories. Included are low-cost, software-based
solutions well suited for stable systems with modest hardware and software
interaction, as well as hardware-assisted tools that support some or all phases
of the design cycle.

Debug monitors
Software-based debug tools known as debug monitors or ROM monitors are probably
the most popular and lowest-cost approach to in-target code debugging. Monitors
are special-purpose programs that reside in the target and are executed when
control is passed via a software breakpoint or interrupt. Once executing, the
monitor provides read/write access to memory, registers, and other system
resources. These functions support code download, memory and register
modifications, establishing software breakpoints, and re-directing software
execution.

The host computer downloads code and commands through a communications port.
This approach lets the developer use break-and-browse debugging. In this
method, the system runs until a breakpoint is encountered and control is passed
to the monitor and the developer browses the state of the stopped system.
Overall debug performance is dictated by the target resources allocated to the
monitor. The communication channel between the target and host must be resident
in the target.

Debug monitors work well in stable target systems where debugging requirements
do not include real-time measurements or evaluation of hardware/software
interaction. They are widely adopted by software debug and real-time
operating-system (RTOS) vendors, and are often used as a field debugging tool.
The ROM monitor's major limitation is its dependence on target system hardware
and software for debugging. Because the monitor is a software program it is
susceptible to system crashes and provides little recovery or history
information. Hence, when debug capability is most needed, it is unavailable.

JTAG emulators
Joint Technical Advisory Group (JTAG) emulators provide many of the functions
of debug monitors with fewer drawbacks. These on-processor debug tools use
resources and microcode built into the processor. Dedicated pins on the
processor provide communication between the on-chip debug interface, external
hardware controller, and input and output to the host computer's debugger.
Host-target communication can be fast, provided via a serial or Ethernet
connection. This approach offers higher code throughput than debug monitors,
does not consume target system resources, and is less susceptible to software
crashes.

The actual performance of JTAG emulators is directly linked to their
implementation. For instance, a JTAG emulator with the background debug mode
(BDM) found on some Motorola processor families can operate at very high
speeds, offering code-downloading rates in the range of 2 to 4 Mbytes/min.
Other JTAG implementations, with roots in board test, have scan chains, with
all changeable or readable bits connected in a serial shift register. These
make code downloading to the target much slower–typically from 200 to 400
Kbytes/min.

Regardless of the implementation, JTAG emulation is superior to the debug
monitor approach. Its primary limitation is that few microprocessors have it. A
more subtle limitation is the background nature of this tool. That is, when in
debug mode, the target code, including interrupt service, is stopped. This can
cause serious run-in target complications.

ROM emulators
ROM emulators offer code downloading and run control,adding reusability and
processor independence. These tools connect to the target system through its
ROM sockets, allowing download of code directly into memory from the host
computer.

By connecting through a direct hardware interface, this tool eliminates the
need to intrude upon serial or Ethernet port resources. The ROM emulator
provides the serial or Ethernet connection to the host.

Advanced ROM emulators such as NetROM (see Fig. 1 ) provide communication
gateway services between the host and target. The target executes a debug
monitor, but instead of communication via a physical serial or Ethernet port on
the target, NetROM provides a virtual connection to its Ethernet port. It also
features JTAG emulation. This approach provides 2 to 4-Mbyte/min downloads,
robust processor control, breakpoints in ROM or RAM space and a
high-level-language debugger connection.

JTAG control is available from the host to the target via a hardware interface
containing a LAN connection. Thus, fast code download and run control is
possible for a very wide range of microprocessors with a reusable tool.

Logic analyzers
Logic analyzers are useful for debugging asynchronous events in target systems
(for example, waveform transitions and signal levels), bringing up new
hardware, and synchronous measurement of bus states. Software debug facilities
are often added to the core functions of logic analyzers.

Some vendors' instruments can match source lines with raw processor cycles.
This display, along with timing waveforms, allows hardware developers to
correlate certain real-time software interactions. Combining a logic analyzer
with run-control tools, such as JTAG emulators or ROM monitors, creates a
loosely coupled test environment that bridges hardware and software
development.

While workable, this approach does not offer a truly comprehensive software
debug environment. A large element of integration is missing between logic
analyzers, run-control tools, and high-level-language debuggers because of
their fundamentally different purposes, disparate interfaces, and operating
characteristics.

In-circuit emulators
In-circuit emulators are the premier tools for code debugging during software
development and hardware/software integration. they offer optimized run
control, real-time trace and event measurements, memory substitution, and a
familiar high-level-language debugging environment.

These tools also provide high-speed code download and a processor-centric view
of the target system's operation. Recent advances in emulation software provide
a RTOS-aware view of the embedded system.

There are several varieties of emulators, designed for specific microprocessors
and processor families and having features to meet varying user needs. The
emulators are connected to the target system's processor through an active
probe and controlled from the host computer.

Working in a multi-windowed environment, a developer can debug from a shell's
command line or with a mouse. Simultaneously, other windows show structure
elements, stack values, call traces, register values, and interleaved source
and assembly level code as well as pure source code. Real-time trace displays
include variables, functions, and source statements, complete with accurate
flow and data references.

From the perspective of getting the product to market, emulators offer the
software developer a high degree of confidence that they can debug the target
system and meet schedules. This time-to-market benefit must be weighed against
the cost and processor specificity of the emulator.
Recent advances in in-circuit emulation allow low-cost and small-form-factor
emulators to be developed. An example of full featured emulation with
convenient packaging is the CodeICE line (see Fig. 2 ).

Software test tools
With more powerful microprocessors finding their way into
embedded systems, the software used to control them and the system itself is
becoming extremely complex. Ensuring that the code performs to specification,
and will not fail in mission-critical real-time applications, is of paramount
importance. Code performance, code coverage, memory allocation analysis and
trace analysis, are now critical factors in system software design and test.
To meet these new challenges, tools known as code testers have recently become
available (see Fig. 3 ). They provide a suite of software analysis tools useful
in all phases of product development.

Code testers connect to the target system through a passive processor-specific
probe and run over a network allowing all team members access to the target
system. They monitor the entire software program at once, eliminating the need
to determine which part of the program to watch and which type of measurement
to perform.

Using code testers, software can be analyzed at either the unit or system level
to identify and correct memory allocation errors and determine code coverage. A
code-tester trace can reveal how the software is interacting with the RTOS.
During integration testing, performance can be assessed at the RTOS or function
level to uncover mysterious execution relationships. Dynamic memory
allocations, common in RTOS-based products, can also be observed and tested
under a variety of conditions.

For post-integration system testing, a variety of test suites with
predetermined degrees of code coverage and performance can be run on the target
system. These suites determine which tests are truly incremental, while
eliminating those that are ineffective.

CAPTIONS:

Fig. 1. NetROM is a ROM emulator that emulates up to 1 Mbyte ROM and allows
ERthernet access.

Fig. 2. CodeICE i960Hx is a full-featured i960 emulator fitted into a small
package through the use of ASICs.

Fig. 3. CodeTAP-XA is an extended version of the original CodeTAP 186 and
provides capabilities between the original CodeTAP and a full-featured
in-circuit emulator.