11.5 A Word on Hardware Tools
Throughout this chapter we have mainly concentrated on software tools for debugging embedded Linux software. In addition to these, there are a slew of hardware tools and helpers for debugging embedded software. As I said earlier in this chapter, the use of a particular operating system for the target makes little difference to the way you would normally use such hardware tools. Though hardware tools are sometimes more effective than software tools to debug software problems, one caveat of hardware tools is that they are almost always expensive. A good 100 Mhz oscilloscope, for example, costs no less than a thousand dollars. Let us, nevertheless, review some of the hardware tools you may use in debugging an embedded target running Linux.
The most basic tool that can assist you in your development is most likely an oscilloscope. As we saw in Section 11.3.5, it can be used to measure interrupt latency. It can, however, be put to many other uses both for observing your target's interaction with the outside world and for monitoring internal signals on your board's circuitry.
Though an oscilloscope is quite effective at monitoring a relatively short number of signals, it is not adapted for analyzing the type of transfers that occur on many wires simultaneously, such as on a system's memory or I/O bus. To analyze such traffic, you must use a logic analyzer. This allows you to view the various values being transmitted over a bus. On an address bus, for example, the logic analyzer will enable you to see the actual addresses transiting on the wires. This tool will also enable you to identify glitches and anomalies.
If the problem isn't at a signal level, but is rather caused by faulty or immature operating system software, you need to use either an In-Circuit Emulator (ICE), or a BDM or JTAG debugger. The former relies on intercepting the processor's interaction with the rest of the system, while the latter rely on functionality encoded in the processor's silicon and exported via a few special pins, as described in Chapter 2. For many reasons, ICEs have been gradually replaced by BDM or JTAG debuggers. Both, however, allow you to debug the operating system kernel using hardware-enforced capabilities. You can, for instance, debug a crashing Linux kernel using such tools. As a matter of fact, the Linux kernel is usually ported to new architectures with the help of BDM and JTAG debuggers. If you are building your embedded system from scratch, you should seriously consider having a BDM or JTAG interface available for developers so that they can attach a BDM or JTAG debugger, even though it may be expensive. Most commercial embedded boards are already equipped with the appropriate connectors.
There is at least one open source BDM debugger available complete with gdb patches and hardware schematics. The project is called BDM4GDB and its web site is located at http://bdm4gdb.sourceforge.net/. This project supports only the MPC 860, 850, and 823 PowerPC processors, however. Though this is quite a feat in itself, BDM4GDB is not a universal BDM debugger.
The LART project (http://www.lart.tudelft.nl/) provides a JTAG dongle for programming the flash of its StrongARM-based system. This dongle's schematics and the required software are available from http://www.lart.tudelft.nl/projects/jtag/. Though this dongle can be used to reprogram the flash device, it cannot be used to debug the system. For that, you still need a real JTAG debugger.
If you are not familiar with the subject of debugging embedded systems with hardware tools, I encourage you to look at Arnold Berger's Embedded Systems Design (CMP Books), and Jack Ganssle's The Art of Designing Embedded Systems (Newnes). If you are actively involved in designing or changing your target's hardware, you are likely to be interested by John Catsoulis' Designing Embedded Hardware (O'Reilly).