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.

[EEVmarty]

So.....What is the *FIX* for this problem? Just throw a blob of black resin (or nail polish) over/around the chip???

It's a bit like leaving the sticker off an Eprom window and waiting for it to go flakey lol

Marty.

[Howardlong]

What a terrible situation, amazing that they didn't consider such a use case during testing. I am sure none of us professional electronic engineers will have ever made such a fundamental life threatening school boy error as this in their lives.

I mean, the original Pi couldn't even deal with 12V shoved up it, what shocking design. http://youtu.be/lYf9HK-rI1s

In other news, 99% of eevblog viewers learned something new new today, while the other 1% pretended they didn't. 

/sarcasm

[EEVmarty]

99% of us don't bother with those 1 percenters  ;-)

What a terrible situation, amazing that they didn't consider such a use case during testing. I am sure none of us professional electronic engineers will have ever made such a fundamental life threatening school boy error as this in their lives.

I mean, the original Pi couldn't even deal with 12V shoved up it, what shocking design. http://youtu.be/lYf9HK-rI1s

In other news, 99% of eevblog viewers learned something new new today, while the other 1% pretended they didn't. 

/sarcasm

[SydB]

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.

We have exactly an application where we must use a CSP package exposed. We need a suitable underfill product. Anybody know of one easily available in the UK? Have to be careful of cure shrinkage, need low viscosity etc.

By the way, WE had to tell the distributor that this could be a problem. Some datasheets note this, many do not!

[Fungus]

So.....What is the *FIX* for this problem? Just throw a blob of black resin (or nail polish) over/around the chip???

Ummm.... how about just not taking photos of it with Xenon flash tubes? Stick to the LED flash in your cellphone and you'll be fine.

[EEVmarty]

So.....What is the *FIX* for this problem? Just throw a blob of black resin (or nail polish) over/around the chip???

Ummm.... how about just not taking photos of it with Xenon flash tubes? Stick to the LED flash in your cellphone and you'll be fine.

No, it goes beyond that, i don't like having open can'o'worms on my boards if i use such devices.
While the Xenon tube scenario is in intense demonstration, i'm sure other sources of IR can be equally disruptive.

From now on, nobody should house their 'pi' in a clear box, or bare board in a cupboard etc where "at some stage" IR could flood the project and kill it.

Prevention..................better than cure!!!!!!!!!!

I don''t have a cellphone either, i use an odd thing called a camera....it might catch on ;-)

[mikeselectricstuff]

Has anyone tried a TV remote close-up? - the peak IR output is pretty high

[EEVmarty]

Has anyone tried a TV remote close-up? - the peak IR output is pretty high

or, that daylight stuff....it could stop a 'pi' in an outdoor project.

I think the next step will be to test various types of resins or potting compounds, maybe even paint or an acrylic nail polish as mentioned earlier, they might all shield intense IR light, they might not....they need to be proven though.

[Jimmyh]

Has anyone tried a TV remote close-up? - the peak IR output is pretty high

I tried a remote right on top of the chip, but it didn't cause a reset.  So far apart from a xenon flash, the only thing that causes a reset for me is the green laser pointer, with or without an IR diode to block the green light.

[JBaczuk]

Another gripe about those bare silicon chips is it's very difficult to see any marking in order to get the package assembled on the board in the correct orientation.  I had this problem with an EEPROM chip and it set us back a couple weeks.   

[Fungus]

Has anyone tried a TV remote close-up? - the peak IR output is pretty high

or, that daylight stuff....it could stop a 'pi' in an outdoor project.

Wouldn't it normally be in a box?

[kayvee]

Another gripe about those bare silicon chips is it's very difficult to see any marking in order to get the package assembled on the board in the correct orientation.  I had this problem with an EEPROM chip and it set us back a couple weeks.   

Ah... the virtues of First Article Inspection.  Must have been a painful experience

[tarheels100]

I wanted to clear up some of the science behind this effect.

First off, perhaps a better term (than the photoelectric effect) for the physical origin of this light sensitivity is the photovoltaic effect.  This is what is responsible for the light sensitivity of PN junctions in photodiodes, LEDs, transistors, etc.  The photoelectric effect, wherein an electron is ejected from the material into vacuum, isn't really going to be very relevant under the circumstances tested here.  The absorption of light by the silicon at the PN junctions in the device is the dominant source of photocurrent when exposing semiconductors to near-UV, visible, and IR light (like a xenon flash).  The bandgap of silicon is at a wavelength of about 1100nm and so any light with wavelengths shorter than that will be absorbed (up until about 400nm), inducing a photocurrent in the device.

Now, the thing that everyone seems unable to explain is why a xenon flash can do this while a flashlight or other light sources can't.  The explanation for that is all in the peak intensity of the light.  Most light sources are continuous, meaning they put out essentially constant light intensity.  A xenon flash, however, is a pulsed source, delivering a huge amount of light in a very short period of time (on the order of microseconds).  The peak intensity of a xenon flash is likely several orders of magnitude higher than even very bright flashlights.  This means that the flash is able to produce a large amount of photocurrent all at once, destabilizing the IC.  A flashlight on the other hand, even though very bright, only produces a trickle of photocurrent by comparison, which the IC is able to handle (dissipate) easily.  You can imagine that PN junctions form a sort of RC high pass filter that passes the xenon flash but not the flashlight.  Likewise, an LED flash doesn't cause the effect since it produces a longer pulse of light and with much less intensity.  So in short, the xenon flash is unique in the shortness of its burst of light.

Overall, I would predict that light in the wavelength range of 1100nm to ~600nm is the main culprit and that there is a peak intensity threshold necessary for causing the RPi to crash. 

[artag]

I tried a remote right on top of the chip, but it didn't cause a reset.  So far apart from a xenon flash, the only thing that causes a reset for me is the green laser pointer, with or without an IR diode to block the green light.

I've tried a red laser pointer. That caused a reset. With some masking around the edge of the chip it didn't (but a xenon flash still did).

[Fungus]

So in short, the xenon flash is unique in the shortness of its burst of light.

What if it's in daylight and you walk in front of it?

Do the sudden changes between light/shadow crash it?

[BarsMonster]

Dave, silicon is transparent to IR light, right where PN-junctions starts to loose sensitivity.

So photons to blame are between 1050nm and 1100nm wavelength: silicon is somewhat transparent there (so light can reach bottom of the die, where transistors are) and PN-junctions are still slightly sensitive.

Light with other wavelength (i.e. red laser pointer) can cause reset only if you shine it from the side, so that light does not need to go though the die.

[Howardlong]

If I shine a decorator's lamp with a 400W R7s halogen bulb at a Pi 2, it goes la la too.

The tube itself needs to be about 6" to 8" away to reboot it (mine reboots, it doesn't seem to hang). You can simply bring it closer and closer in, and then it goes bye bye.

Anecdotally, coming in from an exposed side of U16 seems to be slightly more susceptible, but it resets from the top and even the back of the PCB.

[Paul Price]

For some unreasonable reason, you have all fixated  your thoughts that light is causing the problem. You haven't proved anything if you fail to investigate electromagnetic EMI effect.

How do you know it is not due to an electromagnetic effect?  It could easily be that a voltage is induced in some wire on this pcb by the very high electromagnet energy,  the high voltage delivered to trigger or the xenon lamp or the power dump itself into the lamp creates a high power EMI pulse  that initiates a reset

[ruffy91]

For some unreasonable reason, you have all fixated  your thoughts that light is causing the problem. You haven't proved anything if you fail to investigate electromagnetic EMI effect.

How do you know it is not due to an electromagnetic effect?  It could easily be that a voltage is induced in some wire on this pcb by the very high electromagnet energy,  the high voltage delivered to trigger or the xenon lamp or the power dump itself into the lamp creates a high power EMI pulse  that initiates a reset

This has been discussed numerous times and has been disproved as it is possibe to reset the Pi with a laserpointer.

[tecman]

We had done some work on similar issues some years ago and found that the major culprit was not light, but the EM pulse.  As stated, there is a cap charged to several hundred volts and discharged in milliseconds.  There is a high current of many 10's of amperes in the form of a fast pulse.  This generates a significant high frequency EM radiation which can infiltrate and disrupt any number of devices.

I suggest that Dave use his fancy EM probes and look at the levels produced by the xenon flash.

paul

[Monkeh]

We had done some work on similar issues some years ago and found that the major culprit was not light, but the EM pulse.  As stated, there is a cap charged to several hundred volts and discharged in milliseconds.  There is a high current of many 10's of amperes in the form of a fast pulse.  This generates a significant high frequency EM radiation which can infiltrate and disrupt any number of devices.

I suggest that Dave use his fancy EM probes and look at the levels produced by the xenon flash.

paul

Bluetac or a plastic box should not be effective at stopping this effect. And yet..

[German_EE]

We had a kitchen timer that has a similar problem. The outside case is white plastic and when the kitchen light is turned on (a ceiling fluorescent) the startup pulses reset the timer. The cure was some aluminum foil on the inside of the case.

The chip in this case is a COB under a layer of epoxy.

[SeanB]

EM pulse will be a common stopper for electronics, but here it is the visible light penetrating the substrate.

I wonder if a drop of Loctite black superglue applied to the chip will act as an effective protection. It is opaque and sets into a flexible coating. Otherwise black non magnetic toner mixed with some thin laquer might be a cheap fix as well, otherwise you will need some underfill material.

[Howardlong]

For some unreasonable reason, you have all fixated  your thoughts that light is causing the problem. You haven't proved anything if you fail to investigate electromagnetic EMI effect.

How do you know it is not due to an electromagnetic effect?  It could easily be that a voltage is induced in some wire on this pcb by the very high electromagnet energy,  the high voltage delivered to trigger or the xenon lamp or the power dump itself into the lamp creates a high power EMI pulse  that initiates a reset

Er, no. Look at my post immediately before yours.

I deliberately tested for a transient by bringing the halogen lamp in gradually with it switched on. As the light is gradually brought in closer, it resets.

[TheEPROM9]

Dave one thing occurred to me while watching the video. It would be interesting to repeat the test but with the camera at different distances so you could separate the EMI noise from the light and see how it effects the circuit. Also it might be worth repeating the test but attaching different wavelength filters to the flash and seeing how that effects the results and what wavelengths are the ones responsible for causing the reg to drop out.

[necessaryevil]

On hackaday there is someone who mentions that a cheap green (middle of the visible spectrum) laserpointer will set it off to [1]
And on the raspberry pi site a laser pointer is mentioned too. They are talking about light with long wavelengths, so that wouln't be UV![2].
Wikipedia mentions a elektromagnetic spectrum wavelength wave range from 190-1100nm for silicon photodiodes. [3]

[1]http://hackaday.com/2015/02/08/photonic-reset-of-the-raspberry-pi-2/
[2]http://www.raspberrypi.org/xenon-death-flash-a-free-physics-lesson/
[3]http://en.wikipedia.org/wiki/Photodiode#Materials
I
 think it is just a small problem - whoever caused it.  It is a very specific condition, normally electronics are in an enclosure. 

[EEVblog]

Also it might be worth repeating the test but attaching different wavelength filters to the flash and seeing how that effects the results and what wavelengths are the ones responsible for causing the reg to drop out.

I tried a UV filter without any change in result.

[TheCommonCathode]

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.

Hey Dave, have you looked at this chip that's circled in red? From what I saw, it seems like bare die as well, not just the the one in blue. Since it's near the HDMI connector, could it be just locking up the display (either the driver on board, the monitor, or just the bare die)? It seems like it could be another culprit.

[TheEPROM9]

Also it might be worth repeating the test but attaching different wavelength filters to the flash and seeing how that effects the results and what wavelengths are the ones responsible for causing the reg to drop out.

I tried a UV filter without any change in result.

Saw someone else had suggested that, sorry for repeating, still might be worth testing at different distances. Maybe IR and visible light filters might be worth playing with. This could help narrow down the wavelength.

[wraper]

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.

Where did you get that they are supposed to be underfilled? Actually most of them usually are not underfilled on the mobile phone PCBs. Depends on the phone model and manufacturer, for example, Nokia did underfill very rarely and only 1-2 biggest micro BGA chips on the entire PCB. Samsung on the other side did underfill a lot, often with transparent compound.
I don't see this to be a failure or reason to blame someone at all.

[thm_w]

By the way, WE had to tell the distributor that this could be a problem. Some datasheets note this, many do not!

I don't expect a distributor to have any technical knowledge (other than storing, packaging), but maybe that is just me.


I looked for a random fairchild WLCSP DC/DC converter: https://www.fairchildsemi.com/datasheets/FA/FAN48610.pdf
There are two part numbers, with or without backside lamination. Explanation on lamination from maxim:

Backside wafer lamination (protective polymer film) is used for all Pb-free WLP products. This polymer material is included for both mechanical and UV light protection of the backside silicon surface.

But from Fairchild app note (https://www.fairchildsemi.com/application-notes/AN/AN-5075.pdf), they seem to actively discourage using it:

Backside laminate (BSL) is not a default option for Fairchild WLCSP, but it can be added at customer request. Through the course of WLCSP development, Fairchild has demonstrated that BSL is neither a necessity for backside silicon chipping, nor a significant factor for board-level reliability. Light-sensitive circuit protection, as claimed in literatures, is not a reality concern since silicon is only transparent to long wavelength light, which is rarely encountered in broad applications of WLCSP. BSL is an addition to standard Fairchild WLCSP, but slightly higher cost should be expected due to additional material cost and manufacturing processing steps.

I think they could be more clear here. The fact that Maxim does use it on all of their products indicates it does have value.
Of course I don't know if the RPi2 chip is using the laminated package or not..

[Kaptein QK]

LOL at the camera viewfinder at 7:16 in the video

[CRCasey]

Hay Dave,

How about using this to explain what would happen if there was an EMP?  Either human caused or solar.

-Cecil

[Someone]

On hackaday there is someone who mentions that a cheap green (middle of the visible spectrum) laserpointer will set it off to [1]
And on the raspberry pi site a laser pointer is mentioned too. They are talking about light with long wavelengths, so that wouln't be UV![2].
Wikipedia mentions a elektromagnetic spectrum wavelength wave range from 190-1100nm for silicon photodiodes. [3]

[1]http://hackaday.com/2015/02/08/photonic-reset-of-the-raspberry-pi-2/
[2]http://www.raspberrypi.org/xenon-death-flash-a-free-physics-lesson/
[3]http://en.wikipedia.org/wiki/Photodiode#Materials
I
 think it is just a small problem - whoever caused it.  It is a very specific condition, normally electronics are in an enclosure.

As mentioned above most green laser pointers actually radiate a lot of IR, because they are a pumped solid state laser:
http://en.wikipedia.org/wiki/Diode-pumped_solid-state_laser
The IR emission will be centred somewhere around 1060nm.

[necessaryevil]

As mentioned above most green laser pointers actually radiate a lot of IR, because they are a pumped solid state laser:
http://en.wikipedia.org/wiki/Diode-pumped_solid-state_laser

Thats another thing which points to IR! Anyone got an IR powerled?? I have one, but the problem is that I don't have a raspberry pi 2  

[mikro]

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.

Hey Dave, have you looked at this chip that's circled in red? From what I saw, it seems like bare die as well, not just the the one in blue. Since it's near the HDMI connector, could it be just locking up the display (either the driver on board, the monitor, or just the bare die)? It seems like it could be another culprit.

Yes, this is excatly what I was thinking, and I asked it in this thread at page 2 but no one answered. Has anyone tested this by pointing a laser to this chip?

[Muttley Snickers]

As mentioned above most green laser pointers actually radiate a lot of IR, because they are a pumped solid state laser:
http://en.wikipedia.org/wiki/Diode-pumped_solid-state_laser

Thats another thing which points to IR! Anyone got an IR powerled?? I have one, but the problem is that I don't have a raspberry pi 2

This stuff is a bit beyond me, but I do have a 300 meter 10 degree Bosch BDS-10-8DS infrared illuminator which is 850 nm, in the box, but I dont have a PI.

Also, I foresee those battle robot things getting fitted with Raybans or better still camera flashes, stun your opponent and then whack him on the head.

[EEVmarty]

Yeh, i wonder how many battlebots are now going to "secretly" squirt out floods of IR emissions in hope to wipeout their opponents lol ;-)

As mentioned above most green laser pointers actually radiate a lot of IR, because they are a pumped solid state laser:
http://en.wikipedia.org/wiki/Diode-pumped_solid-state_laser

Thats another thing which points to IR! Anyone got an IR powerled?? I have one, but the problem is that I don't have a raspberry pi 2

This stuff is a bit beyond me, but I do have a 300 meter 10 degree Bosch BDS-10-8DS
infrared illuminator which is 850 nm, in the box, but I dont have a PI.

Also, I foresee those battle robot thing's getting fitted with Rayban's or better
still camera flashes, stun your opponent and then whack him on the head.


Muttley

[Muttley Snickers]

This could dramatically enhance the entertainment factor of those Battle Bot encounters whereby each opponent is permited one flashy thing per bout.

 

[Seaton]

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.

Hey Dave, have you looked at this chip that's circled in red? From what I saw, it seems like bare die as well, not just the the one in blue. Since it's near the HDMI connector, could it be just locking up the display (either the driver on board, the monitor, or just the bare die)? It seems like it could be another culprit.

Yes, this is excatly what I was thinking, and I asked it in this thread at page 2 but no one answered. Has anyone tested this by pointing a laser to this chip?

This is fully explained on the Raspi site blog: http://www.raspberrypi.org/xenon-death-flash-a-free-physics-lesson/#comment-1203682. The device U8 is an HDMI clamping device to meet HDMI spec. It has no apparent effect on the rest of the circuit.

[RupertGo]

As Dave said, this sort of thing does keep cropping up from time to time. It's even been useful; I remember people slicing the top off memory chips back in the day to use them as crude cameras.

More often, it's that kind of bug that keeps you baffled for a bit. In my case, I was writing the low-level code for a Z80 product's floppy drives (the Spectrum +3, in Amstrad's palatial offices), and the test system was a reasonably huge early wirewrapped prototype that took up most of the desk. The dev system was an Amstrad PCW8256 (we used CP/M, it worked well) with a homebrewed hard disk and a Z80 ICE, also fairly chunky, so I couldn't easily sit right over the floppies and run test code at the same time. To make things a bit easier, I blu-tacked (that stuff again!) tiny flags on stiff wire to the heads of the bare floppy drives, so I could sit at the keyboard and watch the head movements from afar.

It was all fairly simple stuff - the NEC uPD765 controller was a docile beast - and one of those satisfying little tasks that lets you feel you're making a lot of progress quite quickly  (and more importantly, so does the boss). But every so often, one or the other, sometimes both, of the drives started to misbehave. The 765 status regs returned curious values, but if you did things like swap the drives the fault stayed with the logical, not the physical, drive. There was nothing up with the breadboard or the controller chip... had to be my code, right?

Pleasurable progress on hold. Often I'd give up at the end of the day and come back in the morning to find everything was fine again for a few hours, but as home time approached the problems came back. They'd go away again later, after I'd missed my train home.

It finally hit me that the fault occurred at roughly the same time every day. The culprit, unusually for Essex, was the sun. As it made its daily path across the sky, its rays tracked through the windows across the office - and when it hit just the right bit of the test setup, it shone on the optical sensor in the drive that spotted the floppy index hole by means of an IR LED shining through from the other side. The result was indeterminate but unwelcome.

Tape applied. Progress restored. Code exonerated. Gods blamed...

R

[BarsMonster]

As mentioned above most green laser pointers actually radiate a lot of IR, because they are a pumped solid state laser:
http://en.wikipedia.org/wiki/Diode-pumped_solid-state_laser

Thats another thing which points to IR! Anyone got an IR powerled?? I have one, but the problem is that I don't have a raspberry pi 2

Power IR led won't help: Their typical wavelength is 850nm or 940nm, You really need something in the range 1050-1100 to reach silicon transparency window.
Otherwise these IR LED will trigger lock only when shining from the side.

IR leakage from cheap green laser pointer without IR filter is a good source: they are leaking 808nm pumping diode (which is useless here) and non-converted IR radiation at 1064nm (which could do the trick).

[vlad777]

I also think that HDMI clamping chip is also to blame.
If you watch the EEVblog video, Raspi DID reset until the Blu-tack was applied to HDMI chip (in second try).

[free_electron]

hasn't anyone noticed that the underfill is missing ?

flipchips are supposed to be underfilled with black epoxy...

that'll solve it.

[darrell]

Now, the thing that everyone seems unable to explain is why a xenon flash can do this while a flashlight or other light sources can't.  The explanation for that is all in the peak intensity of the light.  Most light sources are continuous, meaning they put out essentially constant light intensity.  A xenon flash, however, is a pulsed source, delivering a huge amount of light in a very short period of time (on the order of microseconds).  The peak intensity of a xenon flash is likely several orders of magnitude higher than even very bright flashlights.  This means that the flash is able to produce a large amount of photocurrent all at once, destabilizing the IC.  A flashlight on the other hand, even though very bright, only produces a trickle of photocurrent by comparison, which the IC is able to handle (dissipate) easily.  You can imagine that PN junctions form a sort of RC high pass filter that passes the xenon flash but not the flashlight.  Likewise, an LED flash doesn't cause the effect since it produces a longer pulse of light and with much less intensity.  So in short, the xenon flash is unique in the shortness of its burst of light.

Overall, I would predict that light in the wavelength range of 1100nm to ~600nm is the main culprit and that there is a peak intensity threshold necessary for causing the RPi to crash.

Yes. A cheap xenon camera flash is 5 to 10 kW for about a millisecond, is reasonably efficient and has a rise time of a few microseconds. The capacitor might be 220 uF at 330 V with perhaps 30 amps flowing in the tube at full voltage. Shoe mount units can be 50 kW peak and studio flashes get into the MW range (Speedotron Black Line 2.4 kJ in about 2 ms).

[photon]

hasn't anyone noticed that the underfill is missing ?

flipchips are supposed to be underfilled with black epoxy...

that'll solve it.

Do you think they were trying a new material which didn't work? Or else it's an ultra cheap package that doesn't protect against light? Case must be added for this package?

[Monkeh]

Or else it's an ultra cheap package that doesn't protect against light? Case must be added for this package?

Bingo. It's small and low cost, and not meant to be exposed to sources of bright light. That simple.

An underfill will likely fix the issue, if not, a total capping with epoxy will.

[free_electron]

Those flipchip package always should have a underfill for machanical strentgh alone.

[thm_w]

Those flipchip package always should have a underfill for machanical strentgh alone.

In the Fairchild app note I linked on previous page, they do their testing without underfill:

Unless clearly stated, Fairchild WLCSP is tested without applying under fill materials. WLCSP reliability performances provided are all guaranteed without under fill. However, it is up to the end user to decide whether under fill is applied. It is generally accepted that under fill materials improves WLCSP reliability, as well as helping hold components when reflowed upside down.

I'm not sure if the light is coming from bottom or top.

[andy_silicon]

I did some research about 10 years ago on secure packaging for silicon devices.

A prospective solution was tested - but was defeated with the use a halogen lamp , an undoped silicon wafer as a filter and a cheap black and white cctv ccd camera.

The halogen lamp was placed facing upwards.
The silicon wafer was used to block the visible light.

The specimen was placed above the wafer (thus exposed to IR)

The specimen was viewed with a microscope which had IR capable lenses.
The CCD camera was used to monitor the IR image.

The conclusion.
Undoped silicon is transparent to IR , doped silicon / metal is less so.

So - the conclusion from this is IR is most definately the cause of the issue.

[ConKbot]

No datasheet on a buck converter did someone pay On-semi to develop said controller, and doesnt want it released? I can kind of understand (or i guess more accurately, have gotten used to) broadcom being uppity about their datasheets, but wtf on a smps IC. 

[tom66]

No datasheet on a buck converter did someone pay On-semi to develop said controller, and doesnt want it released? I can kind of understand (or i guess more accurately, have gotten used to) broadcom being uppity about their datasheets, but wtf on a smps IC.

Lots of new vendors do this. Sometimes they don't want other manufacturers to make second source parts, which introduces price competition. Much harder to make a second source part without a complete datasheet.

[Ketturi]

When I was kid, I used to toy around with flash and cheap toys and calculators, I managed to erase eeprom or something from currency converter calc and so on. Ordinary glass encapsulated SMD diode could be used as flash detector too (any diode is photodiode as Dave showed). Also, descent flash tube has enough light energy to slightly melt thin black plastic used in floppy disks, tested that too. I wonder if flash light could be used as some kind of debugging method...

[senso]

In laptops its a misery, almost all the recent(newer than 2012) switchers from TI from the BQ family there is no even a draft/preliminary datasheet, one of them is used since 2012 and in the site it says that the chip is in preview, awful to debug the board with no datasheets 

[Howardlong]

It does seem rather counter intuitive to keep data sheets under NDA particularly for commodity parts like voltage regulators. If they're only interested in 6 figure plus volumes I can just about see why there's some reticence, but for the designer it's a reason to not even bother evaluating. In the end, I'd say that especially for jelly bean parts like these, it makes no sense.

[ConKbot]

but for the designer it's a reason to not even bother evaluating. In the end, I'd say that especially for jelly bean parts like these, it makes no sense.

Hmm, browse a preview, and have to deal with an NDA, or hit up TI and use the webbench and have 15 functioning circuits handed to me  That I2c interface better be really slick to justify the hassle 

[mux]

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.

Where did you get that they are supposed to be underfilled? Actually most of them usually are not underfilled on the mobile phone PCBs. Depends on the phone model and manufacturer, for example, Nokia did underfill very rarely and only 1-2 biggest micro BGA chips on the entire PCB. Samsung on the other side did underfill a lot, often with transparent compound.
I don't see this to be a failure or reason to blame someone at all.

I have honestly never encountered a non-underfilled wafer-level package. All WLCSP packages that I worked with or inspected in the past had links to documents describing exactly if and how they should be underfilled. This is a big part of the selection process, too, as packaging doesn't exist for no reason. If you buy an (essentially) unpackaged chip, you generally need to compensate in some respect for the lack of packaging in other ways. So it's either: buy a $0.02 more expensive chip with the packaging and leadframe or spend money on underfill. This is basic component sourcing and layout engineering.

The only reason not to underfill would be if you'd do the systems engineering and decide that no, this application will not encounter the problems associated with unpackaged chips. No moisture, no light. If light isn't an issue, small chips are often not underfilled because moisture can easily diffuse from out of the balls (/r/nocontext will probably quote me on this), but big packages still get underfill. This could very well be the design decision of Nokia in the case you describe. But for the Raspberry Pi, obviously this board will be used bare and in normal consumer environments a lot, so I cannot see why an engineer who is aware of these issues could think it would be a good idea not to underfill. That is why I'm so adamant on the failure of engineering here.

[vlad777]

That clamping chip near the HDMI probably has reverse biased diodes between rails.
This is exactly the configuration when you expect photodiode to react with light, to conduct.
So that chip is overloading the SMPS and creating dip in voltage.

(Raspi did reset until Dave covered the HDMI chip.)

[Monkeh]

That clamping chip near the HDMI probably has reverse biased diodes between rails.
This is exactly the configuration when you expect photodiode to react with light, to conduct.
So that chip is overloading the SMPS and creating dip in voltage.

(Raspi did reset until Dave covered the HDMI chip.)

It's almost certainly not even on the same rails..

Please people, stop jumping to silly conclusions about things which have already been tested properly.

[vlad777]

That clamping chip near the HDMI probably has reverse biased diodes between rails.
This is exactly the configuration when you expect photodiode to react with light, to conduct.
So that chip is overloading the SMPS and creating dip in voltage.

(Raspi did reset until Dave covered the HDMI chip.)

It's almost certainly not even on the same rails..

Please people, stop jumping to silly conclusions about things which have already been tested properly.

It is not jumping and not silly. I give you some theory and some evidence.
I am sorry I don't have raspi to confirm or debunk this idea.

[Mad_with_Power]

A crude analysis of the effect of wavelength on the RasPi Xe flash problem:

I thought the higher frequency light emitted would be the culprit, but a 5mW 405nm (deep violet) laser did not affect the chip at various angles or focus ranges including a pinpoint dot.

However, a 110mW 532nm (green) laser, even at wide focus ranges (lower intensities) consistently caused the Raspberry Pi failure.

My next thought was that since 532nm lasers are frequency doubled in a crystal from a 1064nm (IR) diode, there could be IR leaking through and causing the effect. I had the output analyzed and found less than 5mW in the IR region which should not affect the chip at the very wide focus because it is about as intense as a typical IR LED. I then tried using a remote with an IR LED and confirmed that the IR in the laser was not the cause.

Also tried were: blacklight, 650nm (red) 1mW laser pointer, and xenon strobe though a >99% UV filter. The blacklight and red laser had no effect, but the filtered xenon flash still disrupted the circuit.

So it seems that UV, violet light, and low-intensity IR are not the culprit, but 532nm green light is one of possibly multiple wavelengths causing the issue. High intensity IR could still be one as well.