Page 192 - The Art of Designing Embedded Systems

Troubleshooting 1 79

loop : out (somesort), (some-data)
j mp loop

Based on the clock rate it’s easy to figure the time between OUTS. I’ll
scope the VO line (whatever it is called: IORQ, WO, etc.), make sure the
chip selects are there, and that they are spaced about right. If the system
can run this loop, 90% of the time the kernel of the hardware (CPU, ROM,
RAM, etc.) is functioning properly.
RS-232 is one of the biggest headaches around. It seems no serial
port or routine ever works quite right at first. If you are coding a comm
function that just doesn’t seem to be working, use a scope to see if at least
data is moving around.
Pins 2 and 3 of the RS-232 connector (for both the 9- and 25-pin ver-
sions) have the serial streams. Put a probe on each of the pins to see if there
is any activity. RS-232 usually uses 12- to 15-volt levels, so be sure to
crank the volts/division control to the 5- or IO-volt position. If you see no
data, then the hardware or the code is broken.
Debugging serial code often involves a lot of interrupt fiddling,
queue management, etc. I typically connect a scope more or less penna-
nently to the serial lines so I’ll know instantly if comm shuts down.
It pays to be a little suspicious of your hardware platform when work-
ing with early prototype systems. Being able to run a few checks yourself
will saves a lot of finger pointing and aggravation. especially at 3 A.M.
when your boss is screaming for results.
To a software person, the true value of a scope lies in its ability to
measure the relationship between two signals. Though it’s easy to apply a
pair of inputs to the channel 1 and 2 vertical amplifiers, you must give
some thought to setting up the scope’s trigger system to get meaningful
results.
Suppose your code should respond to an interrupt by driving a pattern
of bits out some port, but for some reason the pattern never seems to ap-
pear. What’s wrong?
Either the code never even tries to access the port, or it is sending the
wrong data. Multiple causes branch from each of these possibilities, but
before you can make further decisions, you’ll need more information.
The first step is to look at the chip select pin on the YO device. If it
is toggling, then at least something in the software is accessing it.
Determining if the correct data is going out is a bit more difficult. If
the device is one of the common ultracomplex high-integration chips, like
an IEEE-488 controller, you’ll have to look at the data going to it during
the YO cycle.