Page 180 - The Art of Designing Embedded Systems

Troubleshooting 167

many bugs at the same time. When ROM accesses are unreliable and the
front panel display is not bright enough, address one of these problems at
a time. No one is smart enough to deal with multiple bugs all at once-un-
less they are all manifestations of something more fundamental.
Step 3: Round up the usual suspects.
Lots of computer problems stem from the same few sources. Clocks
must be stable and must meet very specific timing and electrical specs . . .
or all bets are off. Reset too often has unusual timing parameters. When
things are just “weird,” take a minute to scope all critical inputs to the
microprocessor, such as clock, HOLD, READY, and RESET.
Never, never, never forget to check Vcc. Time and time again I’ve
seen systems that don’t run right because the 5-volt supply is really only
putting out 4.5, or 5.6. or 5 volts with lots of ripple. The systems come in
after their designers spent weeks sweating over some obscure problem that
in fact never existed, but was simply the ghostly incarnation of the more
profound power-supply issue.
Step 4: Generate a hypothesis.
“Shotgunners” are those poor fools who address problems by sim-
ply changing things-ICs, designs, PAL equations-without having a
rationale for the changes. Shotgunning is for amateurs. It has no place in
a professional engineering lab. And, as noted in Chapter 2, the software
equivalent of shotgunning is making changes without a deep under-
standing of the bug. Use an engineering notebook to break the vicious
“change/test” cycle.
Before changing things, formulate a hypothesis about the cause of the
bug. You probably don’t have the information to do this without gathering
more data. Use a scope, emulator, or logic analyzer to see exactly what’s
going on; compare that to what you think should happen. Generate a the-
ory about the cause of the bug from the difference in these.
Sometimes you’ll have no clue what the problem might be. Checking
the logical places might not generate much information. Or, a grand fail-
ure such as an inability to boot is so systemic that it’s hard to tell where to
start looking. Sometimes, when the pangs of desperation set in. it’s worth-
while to scope around the board practically at random. You might find a
floating line, an unconnected ground pin, or something unexpected. Scope
around, but always be on the prowl for a working hypothesis.
Step 5; Generate an experiment to test the hypothesis.
Construct an experiment to prove or disprove your hypothesis. Most
of the time this gets resolved in the process of gathering data to come up
with the theory in the first place. For example. if the emulator reads all
ones from a programmed ROM. a reasonable hypothesis is that CS or OE