EEVblog #716 - Raspberry Pi 2 Xenon Flash Problem Explained

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 is the photoelectric effect responsible?
UPDATE: I have tried a UV filter in front of the flash and the problem remains.

Support the EEVblog through Patreon!

EEVblog Amazon Store (Dave gets a cut):
Donations:
Projects:
Electronics Info Wiki:

[USWaterRockets]

Your example with the LED reminds me of a hack I did a few years ago. We had a flight computer on our rocket we were building to set the world altitude record, it was made super lightweight and the batteries were tiny coin cells.  The computer had a couple of external status LEDs that blinked the state so we could see it from a safe distance. Well, we had a number of accidental launches while building the rocket pressure because we were working out the details of our launcher design.  To conserve battery power, we did not arm the system until it was near full pressure, so if it launched unarmed then the deploy system would never be activated, and the rocket would crash. The hack solution was that I rewrote the software to use one fewer LEDs for status and the other one (that happened to be on an ADC pin) was repurposed as a launch detect light sensor. I used the light sensitivity of the LED as a trigger to arm the deploy system. When the rocket was on the pad, we put a shade over the LED that would pull away if the rocket ever launched prior to being armed. It worked like a charm. Necessity is the mother of invention!

[FranLab]

This is a great one Dave!  I imagine that a little blob of potting will immediately be added there to new units.  DOH!

[aeroscience]

Actually, it doesn't have to be a specific frequency, it just needs to be higher than a specific point. So it's not the infrared light from the flash, it's probably the uv ones.

[dfx]

I always appreciate how happy DaveCAD is!  Just something about that smiley face with the bright sunny post-it!

[rjainv]

The reason ARM processor is locking up might be because this temporary dip in voltage causes it to get lower than minimum voltage needed  for correct operation, slowing down the switching speed of MOS transistors and hence causing timing violations ( setup time for flip flops) for the clock freq it is running at.  The internal SRAMs might also loose the value they were holding at the time of dip if it drops below voltage needed for state retention (~ threshold voltage).

All of this will cause state corruption for the processor logic and can cause the internal FSMs to hang up/get in wrong/bad state.
Normally in a critical processor, there would be a watchdog timer to guard against such hangs and would cause a reset, but perhaps raspberry pi is too cost sensitive to have such a mechanism in place.

[MyCrazyGarage]

I found this by accident 30 minutes ago...and Dave already made a video about this :)

[akn]

U16 isn't the only bare chip on there. U8 (tiny thing, right next to the HDMI port) is the same construction.

[DiegoSpinola]

Hey Dave


So if we were to calculate the minimum frequency for a photon to remove electrons from, say...pure silicon (best case work function 4.60eV ) we'd reach something like 270nm (UV) .. so yeah ... no peak of light, no matter how strong (amplitude) over 270nm (towards visible light) should be able to extract electrons from the surface of a pure silicon crystal...

BUT! (skipping to microelectronics 101 (taking my trusty Sedra/Smith from the bookshelf!)

Bandgap for silicon would be 1.12eV (I'm using Si as an example... it might not be Si but the orders of magnitude are mostly the same for most semi (check table above) ) would put the needed wavelength at 1.1micrometers (IR)

So if we fire enough photons of shorter or equal wavelength than say 1.1 micrometers (again, Si only an example) to overcome the bandgap we should make something that shouldn't be conducting at that moment temporary into a conductor which is more than enough to cause all sorts of craziness in there (current should be proportional to amount of photons (amplitude))


What do you think EEVblog ? 

Diego Spinola (but you can call me Bruce ;) )

[MattExzy]

This reminds of that episode of the Simpsons, Itchy & Scratchy Land - they stopped the killer robots using disposable cameras flashes. As Myth Busters would say - 'plausible!'

[vadzimdambrouski]

IR is low frequency compared to the visible light. High frequency are UV and X-rays

[TediCreations]

This is awesome content. Awesome. Never thought it could happen in electronics. Changed my point of view for electronics.

[ChrisLeeX]

Wow. Loved the explanation of the emp grounding spike :)

[redsquirrelftw]

That's neat, I never really even thought of light being able to affect electronics to that extent, but it makes a lot of sense after you explained it.

[pablosuarve]

Yeah, the explanation given is wrong.  A large number of photons emitted by the xenon flash have a frequency that corresponds to the energy of the bandgap of the semiconductor material.  When these photons are absorbed by the semiconductor, electrons jump from the valence band to the conduction band, resulting in current flow, which screws with the voltages in the chip.

[renesolis]

Dave, you are awsome in all you're tubes videos. !! thankx

[alexhill]

I do love the use of the classic Clive Sinclare solution to the problem.

[Enriquefishies]

Hey Dave! The infrared part of the spectrum can't be the light causing the problems. Infrared light has a lower frequency than visible light. Remember that frequency is inversely proportional to wavelength.

[lightknight]

Great, now i understood the effect eventually. It was always a mystery to me but with this life example i got it.

[joblessalex]

I saw another chip near the hdmi that looks suspect. Perhaps it's a combination of the two?

[tsusec]

At one of my collage courses ( measuring in electronics ) our profesor told us that IR spectrum of light is the most dangerous for semiconductors (i think we were doing something with " optocouplers " ) so this must be true! Thanks Dave for renewing my knwledge