Designing Embedded Hardware

Some Thoughts on Debugging

Debugging is as much an art as a science. You can load a workbench to breaking point with all sorts of expensive test equipment, yet without a logical approach and a clear mind, elusive bugs will never be found. Conversely, by “right thinking,” the strangest of bugs can be isolated with a minimum of tools. While it is true that the more complex the system under test, the harder it is to nail down a fault through detection, it is also true that the most advanced and useful debugging tool you have at your disposal is your own brain. Therefore, learning to debug is learning to think carefully and clearly.

Debugging hardware can be a lot trickier than debugging software. With code, you can always put in some diagnostics to inspect the execution. That’s not to say that debugging software is trivial—far from it. But with hardware, it is often either a case of it all works, or nothing works. Software has the advantage of being able to be brought into operation gracefully. For hardware, you need to have an awful lot working right from the start.

The essence of debugging is establishing what works and what doesn’t work. As designs grow in complexity, finding hardware and design faults can become quite a complex problem.

For example, your embedded system may not be outputting characters through its serial port. Why? Perhaps it’s a bug in the code. Maybe there’s a cable fault. Maybe the RS-232C interface chip is dead. Maybe the serial chip itself is dead. There ...