Page 150 - The Art of Designing Embedded Systems

Troubleshooting Tools 137

As CPUs get more complex, though, all tools have more restrictions
that you, the user, must understand. If the part has cache, will the tool work
with cache enabled? A more insidious-and common-problem stems
from pins shared between several functions. If address line 18, for exam-
ple, can be changed to a timer output under program control, will the em-
ulator gork? Call the vendor and ask for the “restriction list” before buying
any debugging tool.
Real-time trace-Trace captures the execution stream of your code
in real time, displaying it in the original C or C++ source. Trace depths are
measured in frames, where one frame is one memory or I/O transaction-
thus, a single instruction may eat up several frames of storage.
Trace width is given in bits, and generally includes the address, data,
and some of the control busses, perhaps also with external inputs (to show
how the code and hardware synchronize), and timing information. Widths
vary from 32 bits to more than 100.
Trace is most useful for capturing real-time code-such as the
execution of an ISR-without slowing the system at all. It’s generally non-
intrusive.
Trace is mostly associated with logic analyzers and emulators. Be
aware that as CPUs get more complex, many emulators capture only the
address bus in the trace buffer. . . which means you’ll have no view of the
data transactions associated with the code.
Evenr triggers andfilters-Event triggers start and stop trace acqui-
sition. You define a condition (say, “when foobar = 23”); in real time the
tool detects that condition and starts/stops the trace collection. Filters in-
clude or exclude cycles from the trace buffer (it makes little sense, for ex-
ample, to acquire the execution of a delay routine).
Even with the hundreds of thousands of trace frames offered by some
devices, there’s never enough depth to collect more than a tiny bit of the
code’s operation. Triggers and filters let you specify exactly what gets
captured. The skillful use of triggers and filters reduces your need for deep
trace and greatly reduces the amount of acquired data you’ll have to sift
through.
Overlay RAM-also known as emulation RAM-though physically
inside of an emulator, is mapped into the target processor’s address space.
Overlay RAM replaces the ROM or Flash on your system so you can
quickly download updated code as bugs are discovered and repaired. ICES
provide great latitude in mapping this RAM, so you can change between
the emulator’s memory and target memory with fine granularity. A singu-
lar benefit of overlay is that you can often start testing your code before the
target hardware is available.