EEVblog #716 - Raspberry Pi 2 Xenon Flash Problem Explained

[EEVblog]

Dave investigates and explains the Raspberry Pi 2 Xenon flash problem. Where the Pi2 will reset and lockup when a photo is taken of it from a Xenon flash camera.
How and why the photoelectric effect is responsible.

[Someone]

The xenon flash has a lot of the energy in the UV spectrum that the LED flashes do not, but the responsively of silicon junctions peaks in the near IR around 1000nm. As you noted the large amount of IR that a xenon flash emits is likely the cause, and not produced by LED flashes.

[Harrkev]

I wonder how much can be attributed by light leaking in from the bottom of the package around the balls, and how much from light coming though the die (back-side illumination)?

Maybe do a couple more tests -- one with tape around the edge of the die, but the back side (where the part number is) still exposed, and another with tape on the die itself, but nothing around the edges...

[TheEPROM9]

You lucky bugger you got the Pi mark 2. 

Still waiting for them to become available because there is such a back order. 

I have used Pi's in a number of projects from uni work to hacking and when I get time, finishing my Fallout 3 Pipboy. 

[eV1Te]

As already mentioned xenon flashes contains a lot of UV and IR in addition  to the visible light. But most importantly a xenon flash can easily put out about 1,000,000 lumen but for a very short time (let's say 100 us)

Even if you set the flash to a lower power the lumen stays the same, it's only the flash duration that is shortened. So it would probably still trigger the latch up even for a small xenon flash.

Compare this to a LED flash which has much less lumen but shines for about 100 times longer time.

[AlphZeta]

As @eV1Te said, what's causing the chip to latch up is most likely the energy from the ultraviolet region rather than the infrared region as Dave indicated in the video (since E = h c/lambda, the shorter the wavelength the higher the energy) . And the energy released via Xeon discharge is likely much much higher than what can be achieved by a high intensity LED.

For some rough calculation, the energy stored in a capacitor (say 22 uf, 300V) is roughly 1 J,(1/2 CV^2 which is discharged in 0.1 ms which is equivalent of a 10,000 W lamp so your typical LED won't cut it.

[EEVblog]

As already mentioned xenon flashes contains a lot of UV and IR in addition  to the visible light.

Yes, I suspect the UV is the culprit. I did try a UV torch but no joy. It was pretty piss-weak though.

[coppice]

I doubt its all that hard to make a lot of packaged chips crash with a powerful light these days. Many packages are so thin, they are no longer a good approximation to opaque.

[gardner]

I doubt its all that hard to make a lot of packaged chips crash with a powerful light these days.

To me, that is the real story here.  The fact that semiconductor junctions are light sensitive is not news in the least way.  But the fact that a semiconductor package that is not specifically designed to admit light nevertheless does so, to a degree that affects the part's basic specifications? Hold the phone.

I would like to see Mike do this experiment with his tunable monochromatic light source thingie. I bet getting enough light power out of that thing to affect this package would be a tough job, though.

Dave, I think you give the engineering of that voltage regulator too much of a free pass.  Just because it settles back to regulating properly after the flash and doesn't go into some sort of oscillation or something is no reason to be complacent.  The fact is that it drops out, way outside of its presumed specification, in response to plain, ordinary light.  It is 100% common practice that packages are light-proofed and the manufacturer of this part has saved a quintillionth of a penny by ignoring this most sound best practice.  Shame on them.

[ve7xen]

Dave, I think you give the engineering of that voltage regulator too much of a free pass.  Just because it settles back to regulating properly after the flash and doesn't go into some sort of oscillation or something is no reason to be complacent.  The fact is that it drops out, way outside of its presumed specification, in response to plain, ordinary light.  It is 100% common practice that packages are light-proofed and the manufacturer of this part has saved a quintillionth of a penny by ignoring this most sound best practice.  Shame on them.

I wouldn't be so quick to assign all of the blame to TI/National here. Chip-scale and bare die packages necessarily require additional manufacturing steps to control the environment. Most electronics are not exposed to light ever, and in some applications the savings in board area is probably worth it. In this application, probably not really, but the pennies probably do matter.

Anyway, if this wasn't tested or documented, I would say National gets some of the blame, but since the datasheet isn't public (a theme with Raspberry Pi designs?), we can't know, so I'll give them the benefit of the doubt. I also assume that this is probably well known 'industry knowledge' regarding these package styles that the RPi foundation may not be familiar with, or took a bet on. Either way, the Broadcom SoC's brownout detection should probably be able to handle the dropout, at least well enough to reset gracefully. Latchup is bad and can cause permanent damage, so (if that's what's going on here), I'm surprised the SoC isn't protected against it.

I'm curious if they might be able to fix this with BGA-style underfill rather than a full encapsulant, but as someone mentioned, the problem may be as much due to leakage through the substrate as through the balls. I think Si is pretty opaque though, isn't it?

[Monkeh]

Dave, I think you give the engineering of that voltage regulator too much of a free pass.  Just because it settles back to regulating properly after the flash and doesn't go into some sort of oscillation or something is no reason to be complacent.  The fact is that it drops out, way outside of its presumed specification, in response to plain, ordinary light.  It is 100% common practice that packages are light-proofed and the manufacturer of this part has saved a quintillionth of a penny by ignoring this most sound best practice.  Shame on them.

This sort of package does not tend to be exposed to people firing xenon flashes during operation. These things are made to go inside phones, tablets, media players, etc. They're not actually supposed to be sat out in the open.

[coppice]

Dave, I think you give the engineering of that voltage regulator too much of a free pass.  Just because it settles back to regulating properly after the flash and doesn't go into some sort of oscillation or something is no reason to be complacent.  The fact is that it drops out, way outside of its presumed specification, in response to plain, ordinary light.  It is 100% common practice that packages are light-proofed and the manufacturer of this part has saved a quintillionth of a penny by ignoring this most sound best practice.  Shame on them.

There is nothing wrong with the engineering of the regulator. If a designer doesn't know that using an unpackaged die means they need to exclude light they shouldn't be designing. Its the board designer who messed up. A board designed to be used unpackaged most of the time shouldn't be using unpackaged die.

[EEVblog]

FYI I tried using a UV filter on the flash but same result.

[radiocell]

I never realised this wasn't a reasonably well recognised problem. Goes to show...

Back in the day (i.e. Early/mid-1990's?), I messed around with those single chip processors with the glass windows. For those late to this party, the program data stored in those chips was erased with UV light. You can see where this is heading...

So, here I am, with my Philips 87C552 (really expensive!) multipin processor, doing the development, in-circuit emulator plugged in, cables up the kazoo across the bench and into the dev board, and I get the bright idea to take a photo. Naturally, working in the Dark Cave of Engineering Development, I used the flash.

Darn me if I didn't get that sucker to reset every single time I took a photo.

Solution was equally simple. Just added one of those paper stick-on dots from the stationary cupboard right on top of the chip window. The red and green ones seemed to work just fine. That got added to the first spin BOM. Later ones were (marginally) cheaper OTP devices and didn't need it, IIRC...

New Golden Rule: Don't flash near your dev board. Is that a moral directive?

[Paul Moir]

Question:  if COB is so cheap in quantity, what are its disadvantages?  I can only think of repair.  Reliability?

Anyone out there know much about the transmission spectrum of Si is like?  Perhaps those infrared peaks despite their lower energy?

 

[coppice]

Later ones were (marginally) cheaper OTP devices and didn't need it, IIRC...

The OTP devices should have been considerably cheaper in the early/mid 90s, as they were in plastic packages. Windowed packages were almost always expensive ceramic ones. The early windowed packages in the late 70s didn't affect prices much, as the die inside cost a fortune. By the early/mid 90s a windowed ceramic package really pushed up costs, and a plastic package was a huge win.

[mux]

Dave, I think you give the engineering of that voltage regulator too much of a free pass.  Just because it settles back to regulating properly after the flash and doesn't go into some sort of oscillation or something is no reason to be complacent.  The fact is that it drops out, way outside of its presumed specification, in response to plain, ordinary light.  It is 100% common practice that packages are light-proofed and the manufacturer of this part has saved a quintillionth of a penny by ignoring this most sound best practice.  Shame on them.

There is nothing wrong with the engineering of the regulator. If a designer doesn't know that using an unpackaged die means they need to exclude light they shouldn't be designing. Its the board designer who messed up. A board designed to be used unpackaged most of the time shouldn't be using unpackaged die.

WLCSP packages are always supposed to be underfilled in commercial applications. Look in your phone, look in any kind of tight-space electronics and you'll see underfill even around PCB-based BGAs. Both to keep light as well as moisture out, because both can be a real pain.

This is just a major fail on the part of the foundation, and kind of shows (as if we didn't know already) that the layout guy(s) is an amateur. They shouldn't try to design this stuff themselves, just hire a proper system designer.

Question:  if COB is so cheap in quantity, what are its disadvantages?  I can only think of repair.  Reliability?

Anyone out there know much about the transmission spectrum of Si is like?  Perhaps those infrared peaks despite their lower energy?

Well, you can't use normal assembly machines to start. You need an epoxy curing oven and wire bonding machine as well as reflow oven (although curing and reflow soldering is often done simultaneously). Also, not many chips are available as bare die; you really need to go into the millions or more in volume to make that work.

Silicon is sensitive to:
- Diode forward voltage (0.6eV)
- Bandgap (1.12eV)
- lattice constants (varies)
- work function extraction energy (3.something eV?)

[photon]

An interesting package bug. I wonder if the vendor will respin the package or just document the issue. Seems like an infant mortality issue with the recent WLCSP.

Nice physics!

[Codemonkey]

I never realised this wasn't a reasonably well recognised problem. Goes to show...

Back in the day (i.e. Early/mid-1990's?), I messed around with those single chip processors with the glass windows. For those late to this party, the program data stored in those chips was erased with UV light. You can see where this is heading...

Lol, I know those problems well. Around the same time I was working with a windowed EPROM version of ST's ST9 microcontroller (came in a lovely gold & ceramic LCC package and wasn't cheap). We'd just done a board and it all seemed to be going well until we set it up on a different workbench. Damn thing would just do weird things. So, we'd flip the board over and start probing away looking for dry joints etc, everything would work fine. Flip the board back again, weird issues would resume! Eventually it struck that the new bench location was beside a window and the daylight was affecting the IC! Strangely most of the microcontroller seemed unaffected but if I recall I think it was the timer peripherals that were affected worse. As per your solution, one of those sticky dots cured the issues :-)

[mikro]

There seems to be a chip with same package just behind the HDMI connector. Does that one also has the same photoelectric properties, as the power supply?

[G7PSK]

I would like to see a magnetic pulse fired at the Pi, just a big capacitor discharged through a coil. The other blip that Dave showed could be from the inductor picking up the current pulse from the flash. If the reservoir or by-pass cap was bigger would that keep the processor chip running long enough for the regulator to recover.

[coppice]

I would like to see a magnetic pulse fired at the Pi, just a big capacitor discharged through a coil. The other blip that Dave showed could be from the inductor picking up the current pulse from the flash. If the reservoir or by-pass cap was bigger would that keep the processor chip running long enough for the regulator to recover.

A capacitor charged to a couple of kV and discharged through a couple of turns of thick wire will crash a wide range of modern electronics which has not been hardened against such attacks. What would such a test tell you about the relative merits of the raspberry pi.

[EEVblog]

An interesting package bug. I wonder if the vendor will respin the package or just document the issue. Seems like an infant mortality issue with the recent WLCSP.

I doubt they'll bother.
I'd be willing to bet most WLCSP chips can be made to do something weird under the same conditions.

[G7PSK]

I would like to see a magnetic pulse fired at the Pi, just a big capacitor discharged through a coil. The other blip that Dave showed could be from the inductor picking up the current pulse from the flash. If the reservoir or by-pass cap was bigger would that keep the processor chip running long enough for the regulator to recover.

A capacitor charged to a couple of kV and discharged through a couple of turns of thick wire will crash a wide range of modern electronics which has not been hardened against such attacks. What would such a test tell you about the relative merits of the raspberry pi.

I was thinking of a few hundred volts only, I was thinking that the other pulse shown on Dave's scope could have been the magnetic pick up from the current pulse in the xenon tube, that might explain why the pulse was seen even after the blue tack was added and the board turned around.

[Jimmyh]

Could it be that the infrared light is making it through the silicon substrate.  According to Wikipedia silicon is transparent to infrared light above 1.1 um.  The infrared would go straight through the bulk silicon and onto the circuit on the far side.  That would also explain why a UV filter had no effect.
Update:
I just did some testing on my own Raspberry Pi 2.  I tried triggering the problem with an infra-red LED, but that didn't work.  Not surprising, as the flash is much brighter.  I tried filtering the flash with a glass of water, the theory being that water absorbs IR.  But didn't work either.
Then I tried a green laser pointer.  That did work.  The interesting thing about green laser pointers is that they contain a fair amount of IR.  So I grabbed an Infrared PIN diode, the type with the black casing that is transparent to infrared light and used it as an IR pass filter.
That worked, the PI reset even though there was only a faint glimmer of green light. 
Just to be sure it was not the residual green light causing the reset, I filtered the laser pointer with paper and even though there was a lot more visible green light reaching u16 than using the PIN diode, it would not reset.