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.
Cool. The linear reg on the previous models worked perfectly, but was rather less than ideally efficient - 5V power in, but almost all the power consumed goes via the 3.3V rail.
Reports are saying the power supply is causing this fault.
That might not be the case. Bright UV light will create electron hole pairs in the gate of transistors turning them all *on*, which will cause the chip to use much much more power since push pull output stages of logic gates will now be shorting the power supply.
Hence, even though it looks like the power supply is failing, it could simply be the power supply is turning off due to overcurrent.
I am guessing that wrapping it in tinfoil would fix it? I know it works great for stopping the mind-control waves from getting into my head.
They should have used Silverlight instead of Flash.
Years ago when I visited an aquarium I encountered a very strange situation
I was in front of a tank which has 3 electric eels, and in front of the tank there was a 'meter' measuring the power the electric eels were discharging
So I took out my camera (real camera, with powerful Xenon flash light module attached)
Before I pressed the button the Xenon flash was charging (as I said, powerful flash light) and all of a sudden the 'electric meter' in front of the tank indicated that there was an electric discharge from the electric eels
At first I thought it was a coincidence. Then I wanted to take another picture. Again, my Xenon flash light module was charging, and again, there was a jump in the 'electric meter' reading. This second time around I started to suspect that there was a connection in between my Xenon flash light module and the electric eels
The third time around I only use the Xenon flash module. Again I hold it close to the tank, and charge it, and again, the 'electric meter' got another 'shock'. I repeated the experiment the fourth time, fifth time, .... every single time while my Xenon flash module was charging up,. the electric eels inside the tank somehow 'felt' something and gave an electric discharge
I never know the exact reason. My suspicion is that there might be some EMP effect, some wave or some magnetic field, or something like that
What I described happened years ago. I never get the chance to test out my theory
Perhaps someone can test if Xenon flash emits EMP, or not
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.
He only mentions that it crashes, everybody else answers the question yet he now goes by "Discoverer of the PI2 XENON DEATH FLASH !"
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.
I took a picture of my Raspberry Pi 2, you'll never believe what happened next!
TFA found out precisely which chip it is (U16), covering it solves the problem.
The ENIAC Demo Competition
Stop using Flash, it's a persistent vulnerability, and Youtube has an HTML5 video player now.
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 :)
Really not surprising. The pi2 is pretty crappy hardware. So many better micro computers for projects, not sure why 'geeks' obsess over it.
Oh wow. Random uneducated Pi bashing. Especially considering the device causing the problem is the latest and greatest in small SMPS chip regulators and nothing at all to do with any of the parts that are typically quoted in specs and bitched about by ACs on slashdot.
I use both BeathBone Black's and Raspberry Pi's each has their tradeoffs. The BeathBone is better suited complex embedded applications. It has more GPIOs, two built in 200Mhz in-order microcontrollers for real time tasks, it is faster (than the pre Pi 2's), etc. Not every application needs to play video. In fact almost every project I have done didn't need video. Most didn't need a UI.
Each has their strengths and their weaknesses. Each has its niche. There is no such thing as better for all uses.
What do you know I wrote a novel
The Pi was never intended for video playback or a desktop replacement. The main goal was a low cost learning platform.
Only the State obtains its revenue by coercion. - Murray Rothbard
"Nothing like this will be built again"
I've just had a really amazing experience: a guided tour of the nuclear reactor complex at Torness on the Scottish coast. ... Cameras were verboten -- not because of security, but as an operational precaution. 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, triggering a generator trip ...."
http://www.antipope.org/charli...
Inefficient hardware is sometimes justified by development time.
You can spend many days hand-coding an ideal program for a PIC in ASM. Or you can use an arduino, which takes more power, more space and more money, but can be programmed in a tenth the time by anyone who knows C without needing any esoteric knowledge of harvard architecture and tables of port numbers. If you're doing things a bit more complicated like image processing or networking, the same applies to arduino vs pi: The arduino may be able to do your task if you'll put in the days of programming, but with the pi you're dealing with a familiar linux environment and all the classic libraries are there.
I've seen it before back in the day. They are not very efficient but they could cause a critical spike if they are not isolated from a bus.
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.
The device at U16 on Raspberry Pi 2 v1.1 appears to be an ON Semiconductor NCP6343 DC converter provided in a WLCSP-15 package.
Like all CSP packages, the bare die is photosensitive and needs to be protected from incident light if fault-free operation is expected. Usually such devices are embedded in closed cases like cellphones which prevent light ingress.
However, if the normal operating environment includes uncased bare boards or transparent cases (which are both common and normal for Raspberry Pi), then it is imperative that CSP-packaged dies be protected from light by other means such as opaque epoxies or caps, otherwise such devices cannot be expected to operate within specification.
It is a normal part of the engineer's job to understand their product's operating environment and the components they use, and to design accordingly.