Page 151 - The Art of Designing Embedded Systems

138 THE ART OF DESIGNING EMBEDDED SYSTEMS

Today’s Flash-based systems might seem to eliminate the need for
overlay, but in fact Flash programs more slowly than RAM, leading to
longer download times.
Shadow RAM-When the emulator updates the source debugger’s
windows, it interrupts the execution of your code to extract data from reg-
isters, YO, and memory-an interruption that can take from microseconds
to milliseconds. Shadow RAM is a duplicate address space that contains a
current image of your data that the tool can access without interrupting tar-
get operation.
Hardware breakpoints-Breakpoints stop program execution at a de-
fined address, without corrupting the CPU’s context. A software break-
point replaces the instruction at the breakpoint address with a one
byte/word “call.” There’s no hardware cost, so most debuggers implement
hundreds or thousands. Hardware breakpoints are those implemented
in the tool’s logic, often with a big RAM array that mirrors the target
processor’s address space. Hardware breakpoints don’t change the target
code; thus, they work even when you’re debugging firmware burned in
ROM.
Some pathological algorithms defy debugging with software break-
points. A ROM test routine, for example, might CRC the code itself; if the
debugger changes the code for the sake of the breakpoint, the CRC will
fail. There’s no such restriction with a hardware breakpoint.
Hardware breakpoints do come at a cost, though, so some tools offer
lots of breakpoints, with a few implemented in hardware and the bulk in
software.
Complex breakpoints-Simple BPs stop the program only on an in-
struction fetch (“stop when line 124 is fetched”). Their complex cousins,
though, halt execution on data accesses (“stop when 1234 is written to foo-
bar”). They’ll also allow some number of nested levels (“stop when routine
activate-led occurs after led-off called”). Though some tools offer quite a
diverse mix of nesting levels, few developers ever use more than two.
Desktop debuggers such as that supplied with Microsoft’s VC++
usually offer complex breakpoints-but they do not run in real time, and
they impose significant performance penalties. Part of the cost of an ICE
is in the hardware required to do breakpoints in real time.
It’s important to understand that a simple hardware or software
breakpoint stops your code before the instruction is executed. Complex
BPs, especially when set on data accesses, stop execution after the in-
struction completes. On processors with prefetchers it’s not unusual for the
complex breakpoint to skid a bit, stopping execution several instructions
later.