Page 198 - The Art of Designing Embedded Systems

Troubleshooting 185

Don’t have an adequate tool? Don’t despair. Most CPUs include a
single-byte or one-word software interrupt instruction that will serve
equally well. Remove all memory chips (or disable them by putting their
control signals to idle states), and pull the data bus to the value of the in-
terrupt instruction. For example, on any x86 processor, INT3 (OxCC) is a
one-byte interrupt. Z80/180 systems use RST7 (OxFF). Motorola proces-
sors usually have a breakpoint or illegal instruction trap that works equally
well.
By pulling the data bus to this one-byte/word instruction, you’ve
made it impossible for the CPU to do anything but run that particular
opcode. The processor will blindly follow your will by executing the
interrupt.
It will push the system context onto the stack (never doing a POP or
Return), so the stack will march down to zero, and then roll over. Trigger
your scope on the processor’s WRITE line, and watch the addresses as the
stack pointer marches along. What we’ve done is force the CPU to produce
every possible address, in a controlled manner, while not assuming that
any ROM or RAM location works!
Once the ROM works, it seems logical to assume that the code will
run . . . doesn’t it? Well, no. Things can and do go wrong when running
code, so it makes sense to spend a few minutes trying a simple execution
test before getting carried away burning complex things into ROM.
At the processor’s startup location, bum the simple loop described
earlier (OUT to a port, with a JMP back to the OUT) into ROM (or Flash,
if you’re using it). Odds are the loop will run correctly, since we’ve already
checked the busses. Trigger a scope on the write pulse (generated by the
OUT) and see that it comes at a rate correlated to your clock speed.
Next, get RAM working. Bum a bit of code that sets up the RAM
chip select (if required) and that writes a location in RAM, reading the
value back. With the scope, you’ll be able to watch the transaction to en-
sure that the data comes out of RAM just as it goes in. Again, since the
address bus was tested, there’s no need to do an extensive test.
With working RAM and ROM, it’s time to get your real software de-
bugging tools going. If you’re using a ROM monitor, build a serial port
driver and link it all together. A ROM emulator should just plug in and
play, now that the system’s kernel is alive. An ICE or BDM, of course, will
work even without an operating kernel.
Using your debugger, check the YO using the hacking techniques
outlined in Chapter 5.