Contact Us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right. 

Unit 35, the IO Centre, Armstrong Rd
London, England, SE18 6RS
United Kingdom

+44(0)7779606045

We create circuits that are both beautiful and functional
 

Blog

Comments on RaspberryPi 2's 'Xenon Death Flash'

Saar Drimer

It turns out that a component on the new Raspberry Pi 2 is sensitive to high energy beams of a certain spectrum. This causes the RPi to 'hang' and require a hard reset -- here's an official response to the so-called "Xenon Death Flash" failure.

This failure mode is typically called a 'soft error', where no permanent damage is caused and the device will continue operating normally after a reset or a power-cycle. The culprit IC seems to be a switching regulator (U16 on the RPi) that supplies the main processor; the exact failure mechanism isn't clear yet, however. The fix is easy, just cover U16.

In the context of the RPi, this is a non-issue. A robust solution for this type of errors is within the realm of military-, space-, and medical-grade kit, where 'single event upsets' and soft errors are dealt with triple-modular redundancy and radiation hardening. The RPi, I'm certain, comes with a warning that it is not meant for such applications. Regardless, if you're expecting a beyond reasonable robustness from a $35 device that's optimised for cost, you're mad.

This failure is a humble reminder that hardware development is full of surprises. No matter how much you think about all the possible things that could go wrong, there will always be something unexpected that you will lose sleep over (either through worrying about it, and/or all-nighters debugging/fixing a problem so not to delay a launch). If you have a hardware engineer nearby, give them a hug!

There's no way that the RPi engineers could have seen this coming -- shout-out to James, one of the most talented engineers I know -- it's only come to light since the RPi is such a popular product, exposed by default, and people are obsessed with taking photos of it. Now, that's interesting! If it wasn't for the RPi, we might have never been aware of this potential issue. At Boldport, where we design circuits that are meant to be exposed, this is a highly valuable piece of information. In fact, I can dream up scenarios where this can be used as a clever feature! ;)