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.
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.
He only mentions that it crashes, everybody else answers the question yet he now goes by "Discoverer of the PI2 XENON DEATH FLASH !"
Or maybe the glorious eels didn't give a shit about your puny human flash, but your device was interfering with the meter.
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
My impression is that most people are just getting them for cheap ethernet-enabled controllers, not as learning platforms. It doesn't make that great of a learning platform, anyway. Better to get a cheap PC or laptop for that.
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.
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.