Global Sources
EE Times AsiaWebsite
Stay in touch with EE Times Asia
eeBlogs-Article content Home?/?eeBlog?/?eeBlogs
Nickname:?Jack Ganssle???? Articles(193)???? Visits(279347)???? Comments(30)???? Votes(165)???? RSS
Jack Ganssle is a lecturer and consultant specializing in embedded systems' development issues. He has been a columnist with Embedded Systems Design for over 20 years.
Blog Archive
2016?-? Apr.,?? Mar.,?? Feb.,?? Jan.??
2015?-? Oct.,?? Sep.,?? Aug.,?? Jul.,?? Jun.,?? May.,?? Apr.,?? Mar.,?? Feb.,?? Jan.??
2014?-? Dec.,?? Nov.,?? Oct.,?? Sep.,?? Aug.,?? Jul.,?? Jun.,?? May.,?? Apr.,?? Mar.,?? Feb.,?? Jan.??
View All
Comment?|?Add to Favorites

Posted: 04:22:56 PM, 08/04/2011

Hardware Testing

? ?

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 insure 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 year which aims to break this bottleneck. Kozio 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




Views(876) Comments(0)
Total [0] users voted ????
[Last update: 05:59:49 PM, 09/06/2011]
Have Your Say!

Bloggers Say

Got something to say? Why not share it with other engineers?

Just introduce yourself to us, we'll contact you and set you up. Yes, it's that simple!

See what engineers like you are posting on our pages.

Interviews & Viewpoints


Learn how senior executives are seeing the industry from interviews and contributed opinions.

Back to Top