Testing Need Not Be Elaborate and Sophisticated

The olden days…

A long time ago (seemingly) I graduated from university with my engineering degree.  I was lucky, my first job was with a small company and I performed many roles as it applied to developing their new product line.  The product was an embedded strand process control unit. This unit would control older electromechanical systems that were used in the managing of fibers like Kevlar, fiber optics, fiberglass, sutures and Lycra.  I set about understanding the requirements and designing the embedded system.  I picked the Intel 8051 controller, designed the reset circuitry, oscillator circuitry, and external memory, input / output  addressing mechanisms.  I had drawn the design up and a technician wire wrapped the first prototype part (that should give you an idea of how old I may be).

Development Testing

While the technician wire wrapped the prototype, I set about with my simulator to develop the first parts of the software.  Eventually I received the prototype part and then was able to use in In Circuit Emulator (ICE) to continue the software development using the prototype as the target system.  Over time the wire wrap board moved to a prototype PC board and eventually all of the features are developed with debugged and periodic testing along the way.  I became confident that the product was close to launching and handed it over to a person for use in house to help “ferret out” any remaining problems.


One day, the technician came to me with a reported failure; the output from the embedded product to turn off the machine mysteriously quit working and would start working again when the power was removed and the system restarted.  I spent much time in the lab with the prototype and the machine to which it interfaced measure working, exercising the product in the “real environment”.  I had the oscilloscope on select items for scrutiny on the prototype. One of these was the ground signal from the between the prototype and the industrial equipment to which it was tethered.  I noticed that sometimes, there would be a spurious signal coupled onto one of the circuits (now I cannot recall which one) and it was at these times that the interface integrated circuit (of CMOS construct) would not recover. The input to the integrated circuit would change, but the output driving the relay to turn the industrial machine off did not.

Not Elaborate – Improvised Learning

It turns out that the buffer circuit was susceptible to a condition known as “latchup”.  I will not attempt to describe this condition but I will say this was a great learning opportunity (that took considerable hours).  Eventually we re-worked the design to eliminate the possibility of a spurious signal returning to the unit in a way to perpetuate another such condition.  To test this theory, I found an old drill that sparked and arced through the motor vents on the side.  While the prototype unit was working and interfaced with the industrial equipment, I laid the drill with the vent side to the product and would quickly press the start button on then off, causing a small lightning storm above the prototype unit.  Upon passing this level of electromagnetic stimuli, I returned to the industrial system for testing.  I could see not negative impact from this lightning storm above the prototype and I saw no further coupling from the industrial unit onto the prototype .


The story is not about CMOS latchup. It is mostly about product development and testing. I saw a failure due to a transient coupled back into the product.  I found a convenient way to apply similar type stresses (arguably greater than that exposed in the real world) to the product that did not require a great expenditure or highly contrived solution.  While it is true, I cannot mathematically quantify the stimuli to which the unit was subjected, it is equally true that there were no further reports for the product exhibiting this “latchup” phenomenon.

Post by admin