Many years ago I worked in the R&D department of a company which developed and manufactured specialized consumer products. One of our products had a separate power supply which included an LCD display and programmable controls. Those were the days of 8-bit microcontrollers and monochrome LCD displays.
I was tasked with designing a test jig for the main board of the power supply. The test setup I designed was based around a National Instruments data acquisition system, with some specialized control software running on a PC, and an in-circuit programmer which programmed the board with the final software version at the end of the test cycle. Connection to the board was with a manually operated ICT (in circuit test) jig with pogo pins contacting test points on the bottom of the board.
Operation of the test setup was very simple. The operator would place the board on the jig, lower the top plate, scan the serial number and press “test.” For a good board the result “test passed” would appear on the screen, otherwise a message with the nature of the board fault would be shown.
Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale.
The jig was built by a contractor, I built the interface board, wrote the test software, and did the debugging. Everything went well. The boards were tested and programmed, and the tester diagnosed board faults. So, off it went to the production floor.
Trouble started immediately. The tester was flagging the boards as good, but when assembled in the power supplies, the LCD screens were displaying random characters and general gibberish. Some of the power supplies wouldn’t operate properly. Of course, it all came straight back to my desk with a demand for an explanation.
Finding the cause wasn’t difficult, actually, and involved examination of the memory contents.
When testing the jig, I had been working at my own pace. But on the production floor, the technicians worked much faster. As soon as the screen flashed the “pass” message, they would lift the board off the jig within a few seconds. This released the “reset” pin of the microprocessor, and the capacitors on the board still held enough charge to power up the circuit, so the processor would immediately start to run its program for the very first time.
The program would go to the flash memory to retrieve the working parameters, and, finding the memory empty, would start to write default parameters. At this point, the capacitors would run out of charge, and the processor would power off in the middle of a flash memory write cycle, leaving the memory with undefined contents. When powered up after assembly, the processor would find parameters in the memory, not realize that they were corrupted, and put them up on the screen.
The correct fix would have been to re-write the operational software to add more memory checks, but time was short and the software people overworked and in a bad mood, so I simply added a 2-second delay between powering off the test jig and displaying the “test passed” message. After that, it was all plain sailing.
Benny Attar currently works as engineering team leader in an EMC test and certification laboratory.