Dark side of the light
Tales From The Cube: When a new design is exhibiting strange timing bugs, it can be difficult to decide where to begin your debugging. So, set it up on a testbench, hook it up to an oscilloscope, turn on a desk lamp, and get to work.
By Edward Sullivan, Fibertek Inc -- EDN, August 6, 2009
I was trying to get rid of the last nasty bugs in my electronics system. My company builds laser systems, and this system was the latest in a series of small, handheld laser designators for a military customer. I had designed a small control board to operate the laser, and the software was giving me a lot of trouble. I implemented background interrupts for timing-driven control loops, user-interface devices for control and configuration, and a data-communications SPI (serial-peripheral interface) connecting the microcontroller, an FPGA, and a few peripheral devices. Getting everything to behave had been difficult, but I thought I had solved most of the problems and believed I was in the home stretch.
I was wrong. Some intermittent behavior that I had attributed to earlier bugs refused to go away, and I was under pressure to finish the system so we could package and ship it out for a demonstration. I would start the device up, and, within minutes, some odd behavior would begin. An LED that displayed the operating mode of the controller would suddenly start blinking in a pattern that didn’t correspond to any normal state. More alarmingly, the system would sometimes emit laser pulses when it wasn’t supposed to. The variety of bad behaviors indicated a problem with the SPI, which was responsible for programming the FPGA registers that we used to configure and operate the laser.
I was resigned to having my electronics technician tack-solder a bunch of leads to various SPI-related signals and connecting them to a digital oscilloscope to capture and analyze the SPI traffic. If I could find a corrupt message, I could trace it back to its source code and find the bug. There were a lot of SPI messages routinely zipping back and forth on the SPI bus, so I knew it would be a search for the proverbial needle in a haystack.
|
The morning after my technician had prepared the board for its date with the oscilloscope, we started to talk about the debugging plan. He told me that he thought he had identified the source of the problem. “It’s the lamp we’re using on the lab bench,” he said. “The light is giving off noise and messing up your software.” I was excited to learn he had a theory, but its unlikelihood immediately let me down.
“It’s not the light. How could the light be causing the software to get confused?” I said, somewhat scornfully. I turned on the light and shined it at the board, and the LED pattern immediately changed from normal to anomalous. I was stunned. I put a piece of paper between the light and the board, cycled power on the board, and watched the LED blink happily. I removed the paper, and the LED pattern went bad again.
By cutting a hole in the paper about the size of an IC, I was able to selectively direct the light onto each component on the board and soon identified the problem: Light shining on a Bluetooth-interface IC caused the corruption. The Bluetooth chip was connected to the SPI bus for programming, although the connection was unnecessary because the chip’s default settings worked fine. I solved the problem by cutting the SPI lead connections to the Bluetooth part, and the controller buzzed along peachily ever after.
-
See the package description by Shum posted 8/19. Silicon is transparent especially to infrared and the halogen lamp is hot. The conformally coated flip chip would have been passing photons through to where they hit the circuits on the other side and photo electrons at myriad junctions would cause havoc. The mystery is not that it misbehaved under light: the mystery is that the BT functioned merely disconnecting one wire but still exposed to backside lighting. As someone else said, put a sticker on it.
Tanj Bennett - 2009-15-12 16:22:00 PST -
Ed --
Interesting article.
Questions:
1) What kind of light was it (incandescent, flourescent, LED)?
2) Where there any glass diodes (or zeners) near the Bluetooth I.c.?
Tx. in advance.
Regards . . .
P.S.: I learned about light sensitivity in the mid 60's with transistor chip testing.
James S. Nasby - 2009-25-8 11:49:00 PDT -
Root Cause? Light will cause photo currents and subsequently state changes in MOS circuits that are not properly/opaque encapsulated i.e.; COB assembly or UV EPROMs. Noise from light fixture presumably corrupted the Bluetooth chip transmission/reception at the target frequency (2.4 GHz). However the Bluetooth chip should be rejecting out-of-band frequencies. If the noise is in-band, what would FCC say about a 2.4 GHz subharmonic emitting light fixture? What does the chip manufacturer say about this sensitivity to noise or light?
Jeff Wilkinson - 2009-24-8 12:33:00 PDT -
I've had a similar experience with what I had assumed were sealed optical encoders (low cost Grayhill series). Somehow under fairly bright lighting enough light was sneaking through a crack or directly through the plastic housing itself to cause false outputs. Luckily I made the connection pretty quickly or I would have been chasing my tail trying to figure out what the 'electrical' problem was.
It's surprising that light can get through an IC package but I have heard about this for years. Unfortunately it so rarely causes a problem that it's easily forgotten as a cause of erratic behavior. Parts that are susceptable to this should probably have bold warnings on the data sheet! Maybe you should reveal the part number?
Lee Hardesty - 2009-19-8 15:25:00 PDT -
@Thomas Schum
Thanks very much for the follow up. That makes a lot more sense than what I assumed was the case (pun intended).
My world makes sense again...
B. Boyle - 2009-19-8 11:13:00 PDT
