By Jack Ganssle

Hardware Testing

Summary: Board testing is harder than you think, but there are solutions.

Does your hardware work?

One of the most fascinating aspects of embedded development is that we're working in two very distinct camps: the firmware and the hardware, which, until the invention of the embedded systems, were two non-intersecting Venn circles.

One of the most frustrating aspects of embedded development is that we're working in those two very distinct camps. The hardware guys build a board, "verify" it, and toss it over the wall into the firmware group with a Good Hardware Seal of Approval stamped on the thing. Then the software group tries to test their code only to find a series of problems with the PCB.

To double the Embedded Excedrin headache, the problems manifest themselves as software issues. Troubleshooting becomes a nightmare because people are looking in all of the wrong places. Or maybe the board is intermittent, working at times but failing only when specific and hard-to-reproduce events occur.

In the best of cases, how do you even know if your hardware works? Crank out some diagnostics and, sure, with enough time one can ensure that everything functions correctly. Yet some kinds of failures - say, with complex SDRAM logic - require quite complex test code, as failures occur in perverse ways, ways that few of us non-test engineers really understand.

I visited a Colorado company last month which aims to break this bottleneck. Kozio (www.kozio.com) offers a variety of products that perform excruciatingly-detailed tests on custom hardware. Their kDiagnsotics is a program they customize (often in just a few days) to your hardware design. That's possible and cost-effective since the company has a huge library of canned tests they've written for many types of peripherals. Given a board with not much more than a running CPU and a bit of memory, kDiagnostics can exercise the rest of the board and pinpoint design or production errors. With the use of scripts the hardware engineer can loop through tests, or even subsets of tests, to create known and repeating stimuli to guide scopes and logic analyzers through the troubleshooting process. Said loops can run for an extended period of time to look for glitches, perhaps while cycling the board in an environmental chamber or around ESD discharges.

The upside: the hardware people deliver a known good board to the firmware engineers. The latter can use the tests to prove that a problem really is in the code, not on the board (all hope is not lost; we can still blame the compiler).

Other offerings include a royalty-free POST that can be embedded into your product, a utility that dumps peripheral register contents so you can get insight into how to set these up, and more.

But with hardware getting more complex I think validating it as thoroughly as we test the code is a good idea. Check them out at www.kozio.com.

Published January 29, 2010