Page 191 - The Art of Designing Embedded Systems

178 THE ART OF DESIGNING EMBEDDED SYSTEMS

pulse generator to reset a dead CPU repeatedly, so you can scope the reset
sequence.
Years ago we used a shortwave radio to listen to the operation of our
system’s code. With a little experience we knew what sort of noise to
expect in each of the instrument’s important operating modes. With the
volume turned to a quiet murmur, any change in its buzz instantly signaled
trouble. Troubleshooting is a multisensory experience. Wait! What’s that?
It smells like a resistor burning . . . a wire-wound, by its odor. . . . The
game’s afoot!

Scope Debugging
A lot of developers on a tight budget debug with a scope almost ex-
clusively. Personally, I think this is as bad as never using one. You won’t
get source-level debugging, which pretty much rules it out for applications
written in high-level languages.
A scope complements your tools. By itself it is inadequate; in con-
junction with the rest of the toolchain it is invaluable.
Just knowing how to press the buttons is not enough. That’s a little
like considering yourself educated because you can recite poetry in a lan-
guage you don’t understand. It’s important to know how and when to use
the scope, and what tricks you can play to pry the maximum amount of in-
formation from buggy code.
Is your program running at all? Some embedded systems don’t re-
ally do anything. They just sit quietly, monitoring some value, and pro-
duce an output only if some unlikely or infrequent event occurs. Without
blinking LEDs, are you really sure the unit is alive? Sure, you can use an
emulator or logic analyzer and collect trace data, but the scope provides
an easier alternative. Checking for “aliveness” is the simplest scope oper-
ation, requiring the use of only a single channel and only seconds of setup
time.
Though you can scope the microprocessor’s data, address, and con-
trol busses, it’s rather hard to decide if the CPU is running wild, or if it is
doing what you’d expect. Data and address lines are notoriously ugly, even
in well-behaved systems.
The best solution is to probe the chip selects to your critical YO de-
vices. If the code is polling these, there’s a good chance it is running. If you
wrote the code, you probably have a pretty good idea how often the code
should go to the I/O, which gives a baseline to compare against.
The first program I write on new hardware always looks something
like: