Page 176 - The Art of Designing Embedded Systems

Troubleshooting Tools 163

quick code downloads. If the initialize is not correct, since you’re
debugging from RAM things may work just fine . . . until that first
ROM bum.
Often hardware problems mean that the ROM sockets on your
target just don’t function properly. This may be due to wiring or
design problems . . . or even to buggy code. An improperly con-
figured chip select signal, for example, may not create any prob-
lems working from emulation RAM, but will crash the code after
the ROM burn.

Be wary of the converse situation: the code runs fine from ROM but
not from emulation RAM. All too often a wandering pointer causes erratic
writes over ROM space, surely a very bad thing. This happens so often that
we should take a defensive posture and regularly look for such problems.
Depending on your tools, this is pretty trivial:
Many emulators support modes that will automatically watch for
writes to code space. If the tool doesn’t explicitly include such a
resource, you can still usually configure one of the complex break-
points to break on any “write to address between X and Y,” where
X and Y represent the range of addresses of code.
Occasionally checksum your code. That is, download the code and
compute a checksum of the image using the tool’s checksum com-
mand. Run the application for a while and recompute the check-
sum. Any change generally indicates a serious problem.
Wandering pointers are such a common problem, and are so diffi-
cult to find, that there’s a lot to be said for leaving a logic analyzer
connected that’s configured to watch for errant memory accesses.
The wonderful triggering capability of these tools means it’s easy
to set up multiple conditions that watch for any stupid memory ac-
cess. What do I mean by “stupid’? A write to code space. A fetch
from data areas. Any access to unused memory. Trigger on these
three conditions and you’ll catch a huge percentage of wandering
pointers.