EEVblog #716 - Raspberry Pi 2 Xenon Flash Problem Explained

[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.