Slashdot Mirror
Xenon Flashes Can Make New Raspberry Pi 2 Freeze and Reboot
An anonymous reader writes Unfortunately for Raspberry Pi 2 owners who are trying to photograph their devices, ... the Raspberry Pi 2 has been found to be Xenon flash sensitive. Any camera with a Xenon flash aimed at the device is causing the device to freeze for a few seconds before rebooting. The forum thread about the bug is an interesting play-by-play of how the problem was narrowed down.
Hence, even though it looks like the power supply is failing, it could simply be the power supply is turning off due to overcurrent.
No. Covering the regulator chip solves the problem. That means that it is the culprit.
If that was the case, putting a blob of material on the power supply chip (and nothing else) wouldn't remedy the problem – but it does (see the last post on this page.)
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
This thread shows a quick experiment which confirms it's directly the light which is the cause, not the EM pulse from the capacitor discharge in the flashgun. Chip U16 apparently, which is part of the power regulator.
A 100mW red laser pointer aimed at U16 also triggers it.
Unless you want to claim diode lasers now emit x-rays and low rise time EM pulses... it's light sensitive.
And inspecting U16 closely, it's no surprise. You're not looking at a plastic package but the laser marked underside of a bare die.
Bingo, that's about what I was going to say. U16 is flip-chip bonded to the circuit board, meaning the naked die is exposed on the bottom. Even if it had a plastic or ceramic cover, it might still be photo sensitive to light getting underneath it. If the underside of the die (flipped, so topside) is really exposed, it basically becomes a silicium solar cell.
TFA found out precisely which chip it is (U16), covering it solves the problem.
The ENIAC Demo Competition
It is an illustration of how assembly-line our intelligence has become that we can produce such technological marvels as a Raspberry Pi - a science fiction fantasy just decades ago - but talented engineering teams forget to do something like put packaging on the chip die.
Nobody forgot anything, the raspberry pi is cheap because its crap, and vice versa.
There's plenty of cases of electronics misbehaving due to exposure to strong light. Glass enveloped diodes (such as signal diodes) can be notorious for it, as can the black plastic encased units if the light is strong enough.
Small bare CoG (Chip on Glass) LCD panels will crash / hang when you use the flash on the camera taking photos of them in operation ( same reason, the controller die is exposed ).
It's not EM-pulse or xrays causing the problem, just good ole silicon junctions being exposed to intense light :)
I've worked with Nd:YAG lasers that had large xenon flashlamps in them (in principle like a camera's flashlamp, but much bigger, 100s of kW for a sizable fraction of a second), and pretty much any voltage monitoring in the room would pick up spikes from the start and end of the flash, even with a metal cover over the laser. Any large changes in current and unshielded inductance, and you will get some mess of EMI coming off. I doubt it would be enough to damage anything, unless you had a giant antenna feeding directly into silicon that was within a 100 mV of a damage threshold and no protection scheme.
But sometimes it doesn't take much to confuse some chips and get them into a state they are not supposed to be in. I've seen plenty of driver chips that will, to the detriment of what they are connected to, latch up in noisy environments. They turn on, but don't turn off when the input signal is turned off. I would expect a SMPS to be somewhat robust to such noise considering how often they get used in half-ass designs that spew out plenty of EMI. But I've also seen some of the higher frequency ones that use rather large resistors for feedback, with a feedforward capacitor of just a couple pF, which is small enough it means if unshielded, moving your hand close to the circuit changes output voltage slightly and even the stability if poorly laid out on the board. Even then, it would take a whole mess of layout problems and things being marginal for that to affect the operation of digital logic.
Some one should use this though to run a VIC-20 emulator... then I could relive not so found memories of an experiment I once worked on that would cause the VIC-20 to reboot every time it fired.
That's because you're hearing the pulsed transmission of a TDMA radio technology.
D-AMPS (AT&T pre-Cingular), iDEN (Nextel), and any GSM 2G (up to EDGE) all use/used TDMA to share the frequency, so they're all potential causes of this.
These days you won't hear it much because D-AMPS and iDEN are both dead and most GSM phones will be attempting to connect on 3G UMTS (which uses CDMA) or 4G LTE (OFDMA).
DECT cordless phones are heavily derived from GSM so it's possible that they may be able to cause the same behavior, but due to their significantly reduced range requirements the power probably isn't there. I haven't heard it from my DECT phones.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
It doesn't take much to actually run most CNC setups. That hasn't stopped professional equipment, costing more than thousands of dollars, from having their share of problems and crashing on us or crapping out. More often than not it comes down to user interface stuff or fancy features not used often (I'll do geometry calculations at my desk, not standing in front of the machine) that crap out, but sometimes brings the whole system down. I've seen it even happen when a company rep was demonstrating their new controller for us. At least if we had source code instead of a crappy manual, it would be easier to see ahead of time that a particular controller can choke on a specific combinations of whitespace in the g code, or crazier stuff like splitting a command into two nonsensical ones.
On the other hand, I've seen student RPi projects come through quite often, and we have even few used to monitor equipment, and they just sit there and run 24/7.
For starters, some embedded controllers in racks in the auxilliary deisel generator control rooms have EPROMs which have been known to be erased by camera flashes in the past
That's why people have always put metal foil stickers on the EPROM window to protect them. Even exposure to sunlight can mess up uncovered EPROMs. And a little sticker seems easier and more reliable than making sure not a single camera makes it through security.
They still do this if you're on a GSM network.