[HN Gopher] The Xenon Death Flash: How a Camera Nearly Killed th...
___________________________________________________________________
The Xenon Death Flash: How a Camera Nearly Killed the Raspberry Pi
2
Author : DamonHD
Score : 160 points
Date : 2025-05-24 12:06 UTC (10 hours ago)
(HTM) web link (magnus919.com)
(TXT) w3m dump (magnus919.com)
| pvg wrote:
| HN thread at the time
| https://news.ycombinator.com/item?id=9015663
| DamonHD wrote:
| Thank you!
| xeonmc wrote:
| The intensity threshold was crucial. Regular LED camera flashes
| didn't produce enough photons, but xenon flashes and laser
| pointers packed sufficient punch to trigger the malfunction. Even
| more interesting, the effect required silicon's specific bandgap
| energy--meaning infrared and visible light could potentially
| cause problems, but only at extreme intensities.
|
| Article is confusing intensity with wavelength. Unless they're
| talking about nonlinear multiphoton absorption which could inly
| be achieved by intense ultrafast laser pulses
| goda90 wrote:
| How so? It sounds like they are saying high intensity light
| with wavelengths in the infrared and visible affect the chip,
| suggesting higher and lower wavelengths don't even with high
| intensity.
| rini17 wrote:
| I had same issue with fancy translucent cover for my hearing
| aids. Sunlight at certain angles and flashes caused noise. Nobody
| believed me.
| nickdothutton wrote:
| Reminds me just a little of the "SPARC CPU cache corruption by
| radioactive decay of impurities in chip packaging" which cost me
| many hours in my first job.
| robocat wrote:
| IBM memory chips - great story, which I copied into this
| comment: https://news.ycombinator.com/item?id=25279964
| Sharlin wrote:
| Another classic hardware glitch: iPhones Are Allergic to Helium
| [1]
|
| [1] https://www.ifixit.com/News/11986/iphones-are-allergic-to-
| he...
| K0balt wrote:
| This one was actually pretty cool, since the effect of
| alternative environmental gasses had not been extensively
| documented by MEMS device manufacturers at that time.
|
| It was interesting and remarkable because many engineers,
| despite solid diligence, might have missed the possibility
| unless they were well versed in MEMS manufacturing processes
| which were not very widely known before publication.
|
| Still, it wasn't at all surprising to the manufacturers of the
| parts, since using a calibrated gas mixture for initial
| adjustment is a standard design step.
| stinkbeetle wrote:
| It was documented in Apple's user guide.
| ACCount36 wrote:
| And here's an excellent followup video on helium sensitivity:
|
| https://www.youtube.com/watch?v=vvzWaVvB908
| K0balt wrote:
| Photosensitivity in WLCSP parts is not something that was
| "discovered" by the community.
|
| The data sheets for WLCSP parts specify that the part is
| photosensitive and often give data on how light can affect the
| part.
|
| This has been known since the inception of WLCSP, and is treated
| as a design parameter by responsible engineers.
|
| Chip manufacturers know that bare silicon chips are light
| sensitive, they are literally made of thousands/millions/billions
| of tiny solar panel junctions. CMOS imaging tech evolved from
| exposing cmos memory chips to a focused image. WLCSP chips are
| basically unpackaged silicon chips.
|
| None of this is a "discovery". People have been decapoing
| transistors to use them as photodetectors or solar cells since
| people started putting metal covers on transistors to protect
| them from light interference. Early photo transistors were a
| standard npn part with a windowed can.
|
| If you put WLCSP parts on a PCB that will be unprotected, and
| photosensitivity is not an acceptable design feature, you are
| either a hack, or making mistakes like a NOOB and should be
| supervised by a senior engineer.
|
| It's called reading the data sheet, before integrating a part
| into millions of devices. Maybe understanding what a silicon chip
| is made of and how semiconductor junctions work. It's a basic
| engineering responsibility, and failing to do so is an abdication
| of your duties and responsibilities as an engineer.
|
| Anyway, cool story except I get the definite feel that the
| article was written or heavily influenced by LLM output, by the
| pedantic cadence and constant summarization.
| Maxious wrote:
| We played this monday morning quarterbacking 10 years ago, the
| datasheet Raspberry Pi used said:
|
| > Light-sensitive circuit protection, as claimed in
| literatures, is not a reality concern since silicon is only
| transparent to long wavelength light, which is rarely
| encountered in broad applications of WLCSP.
|
| https://web.archive.org/web/20150210111428/https://www.fairc...
| K0balt wrote:
| Well then, can't really fault the engineers if they told
| users about it. Fun hobby mystery and nobody got killed.
| 10/10.
| Aurornis wrote:
| > Photosensitivity in WLCSP parts is not something that was
| "discovered" by the community.
|
| The article doesn't make that claim. There's an entire section
| titled "This Wasn't Actually Unprecedented". It links to
| another article containing stories about previous examples. It
| discusses the root cause of WLCSP photosensitivity.
|
| > None of this is a "discovery".
|
| The discovery was that the Raspberry Pi 2 was photosensitive,
| not that WLCSP parts are photosensitive. Most PCBs aren't
| distributed to consumers as bare PCBs, so this issue rarely
| appears to end users.
|
| > If you put WLCSP parts on a PCB that will be unprotected, and
| photosensitivity is not an acceptable design feature, you are
| either a hack, or making mistakes like a NOOB and should be
| supervised by a senior engineer.
|
| You're exaggerating. WLCSP photosensitivity is an uncommon
| phenomenon that requires a very strong and specific light
| source (Xenon flash, in this case) and the combination of an
| exposed PCB. I know there's something about the Raspberry Pi
| that makes armchair quarterbacks want to find ways to call
| their engineers "hacks" and "NOOBS" but this is really a rare
| edge case. I wouldn't be surprised if the photosensitivity was
| not even mentioned in the part's data sheet.
| K0balt wrote:
| It's not a rare edge case. Not at all. A lot of WLCSP parts
| will go way out of tolerances if exposed to direct sunlight.
| The thing that makes xenon flashes exceptionally adept at
| triggering malfunctions is a combination of their high
| intensity ant their exceptionally fast rise and fall times.
|
| This vulnerability, where present can be (and is commonly)
| exploited in alarm systems, access control devices, and other
| electronics that may face adversarial incentives. Light-
| protective covers are a very standard feature in construction
| of any kind of critical device that uses WLCSP parts.
|
| In the case of the raspberry pi, the fact that it is a hobby
| device is a pretty good excuse for leaving the devices
| unprotected, but I definitely would have included the fact
| that the design incorporates WLCSP parts in critical roles
| and that the PCB should be in a case if being used in mission
| critical applications, since presumably, designers
| integrating RPI are less likely to be experienced board-level
| engineers.
|
| My comment about being a hack or a noob really wasn't meant
| for the RPI designers, though I can see how it would be easy
| to read it that way. I may be a bit of a literary hack,
| myself lol.
| hnuser123456 wrote:
| Xenon flashes are also fairly broadband and emit UV that
| should be mostly absorbed by the glass/coatings, but maybe
| some still gets out at just the right energy level to flip
| a bunch of transistors. LEDs are comparatively very
| narrowband in the visible region.
| clysm wrote:
| > Most PCBs aren't distributed to consumers as bare PCBs, so
| this issue rarely appears to end users.
|
| In terms of hobby/maker electronics, embedded systems, etc.,
| which the Raspberry Pi falls under, yes they absolutely are.
| The entire Arduino ecosystem is like this.
| swores wrote:
| Raspberry Pi does indeed have users for whom it's in the
| same category as things like Arduino.
|
| But it also has lots of users for whom it is simply a cheap
| computer to plug into a screen / mouse / keyboard, people
| for whom the only interesting things about the hardware are
| its price and size.
|
| (I've no idea what the ratio is, but I would guess the
| majority of customers are the latter type; though possibly
| not the majority of Pi's sold, since the former group
| contains people much more likely to buy multiple devices,
| whether someone like me who's bought a few for tinkering
| with, or someone actually doing something interesting and
| needing either 100s for their own project, or 1000s to go
| into something they're selling.)
|
| So what you said is true for some, but far from all, Pi
| consumers.
| AStonesThrow wrote:
| During the pandemic, there was a noticeable shortage of
| Pis on store shelves. Comments by hobbyists indicated
| that the existing supply was being snapped up by small-
| time manufacturers who had designed commercial products
| around the Pi as a base, and end-users weren't receiving
| priority or first dibs at them.
| KerrAvon wrote:
| Raspberry Pi themselves said they were prioritizing
| businesses over retail consumers at the time; businesses
| need stuff to sell to remain viable.
| timschmidt wrote:
| > You're exaggerating. WLCSP photosensitivity is an uncommon
| phenomenon that requires a very strong and specific light
| source
|
| "In 1967, Dawon Kahng and Simon Min Sze at Bell Labs proposed
| that the floating gate of a MOSFET could be used for the cell
| of a reprogrammable ROM (read-only memory).[3] Building on
| this concept, Dov Frohman of Intel invented EPROM in 1971,[3]
| and was awarded U.S. patent 3,660,819 in 1972. Frohman
| designed the Intel 1702, a 2048-bit EPROM, which was
| announced by Intel in 1971.[3]"
|
| "The programming process is not electrically reversible. To
| erase the data stored in the array of transistors,
| ultraviolet light is directed onto the die. Photons of the UV
| light cause ionization within the silicon oxide, which allows
| the stored charge on the floating gate to dissipate. Since
| the whole memory array is exposed, all the memory is erased
| at the same time. The process takes several minutes for UV
| lamps of convenient sizes; sunlight would erase a chip in
| weeks, and indoor fluorescent lighting over several years.[8]
| Generally, the EPROMs must be removed from equipment to be
| erased, since it is not usually practical to build in a UV
| lamp to erase parts in-circuit."
|
| https://en.wikipedia.org/wiki/EPROM
| KennyBlanken wrote:
| > I know there's something about the Raspberry Pi that makes
| armchair quarterbacks want to find ways to call their
| engineers "hacks" and "NOOBS"
|
| Because they are hacks and noobs? Who puts a WLCSP part on a
| board which is more commonly zip-tied to a piece of wood than
| it is placed into a case, and is more likely to be driving
| some wild contraption shooting RF and UV and god knows what
| else everywhere, than it is sitting inside some nice little
| commercial device like an office labelmaker?
|
| Their hardware is almost always immediately superceded by
| cheaper, faster, better boards because they're not trying to
| give Qualcomm blowjobs clearing out shitty SoCs nobody wanted
| to buy because they were buggy, underperformant, overpriced,
| or all three...and they don't have the market advantage of
| everyone buying whatever garbage they spit out. Other
| companies have to start on the back of their heels so their
| products can't suck.
|
| Their hardware designers are inept with every generation of
| every product they've made having issues and/or promised
| features not making it into production.
|
| Their QA is non-existent despite seeding test boards widely
| where either they're not catching problems before doing into
| production or they're intentionally not fixing stuff because
| it would increase their costs and they know people will just
| snap up whatever garbage the Pi Foundation ships. The
| problems are so bad that you have to ask how they even got
| past internal testing and validation.
|
| Seriously: if a bunch of college EE students worked for a
| semester they could probably build a better product.
|
| Each generation of the Raspberry Pi has had basic hardware
| design flaws showing that their hardware engineering was not
| up to the task of producing the dominant hobbyist (and
| increasingly commercial/industrial, somewhat frighteningly)
| SBC.
|
| Then they fucked up the RP2040, a wildly simpler product.
| When when they released a revised version that fixed the ADC
| issue, _they fucked up GPIO._ How do you fuck up GPIO and not
| notice?
|
| I don't know who the Raspberry Pi foundation employes as
| hardware enginers but whoever their head of engineering is
| should have been fired a long, long time ago.
| the__alchemist wrote:
| Learned something new today! I've used a handful of these. Had
| assumed the term was interchangeable with "BGA" from a design
| perspective. I.e. just pick this one if it's what the part's
| available in, or you want a smaller one than the QFN etc
| variant, and can stomach not being able to visually inspect the
| pins. You can usually get away with the net and footprint
| abstraction if not doing high speed or RF.
|
| You can see how this would be overlooked: a given board may
| have many parts, and data sheets can be long. Usually you get
| good at picking out the important parts: Protocol description,
| pin maps, ref layouts, voltage tolerance etc. Reading the fine
| print certainly would have prevented this, but you can justify
| skipping it. Maybe less justifiable for a device like this
| that's produced in huge quantities though!
| K0balt wrote:
| Yeah, I mean if you're building them for your own amusement
| or in small quantities for noncritical applications, no
| biggie, who has time to read all 300 pages lol? But if you're
| supposed to be engineering a board that will be produced in
| the millions, that extra six hours digesting the important
| notes in the data sheet becomes basic due diligence.... You
| never know what that board is going to end up controlling
| somewhere, and the contributions you make to human happiness
| by making the board more reliable are multiplied by millions.
| skrebbel wrote:
| Offtopic but the phrase "the pedantic cadence" is new to me and
| I love it, thanks. I now finally have the words to express that
| "this feels like LLM output, and it annoys me, but I can't put
| my finger on it why" feeling. It's the pedantic cadence.
| K0balt wrote:
| You're welcome! I was pleasantly surprised to have had that
| roll off of my keyboard as well. It is something difficult to
| elucidate but somehow perfectly encapsulated in "pedantic
| cadence".
|
| Also, Pedantic Cadence (r), the acerbically sarcastic EDA
| software where AI critiques all of your design decisions for
| the best possible engineering result! Only an extra $199 a
| month!
| Animats wrote:
| > you are either a hack, or making mistakes like a NOOB and
| should be supervised by a senior engineer.
|
| Right. Who put a bare chip on an open board and expected it to
| work?
|
| There have been cases of photosensitive parts in the past,
| where the plastic encapsulation didn't have enough carbon
| black. Some old parts were packaged in brown plastic that
| wasn't opaque enough. That's a problem from decades ago.[1]
|
| [1]
| https://electronics.stackexchange.com/questions/217423/ics-c...
| userbinator wrote:
| The whole "maker" phenomenon is full of cases of willful
| ignorance like this. The idiocy of using a part from a
| notoriously closed company and with no public datasheet was
| just the beginning.
| Kirby64 wrote:
| > If you put WLCSP parts on a PCB that will be unprotected, and
| photosensitivity is not an acceptable design feature, you are
| either a hack, or making mistakes like a NOOB and should be
| supervised by a senior engineer.
|
| Not all WLCSP parts have substantial or even noticeable
| photosensitivity issues. The vast majority of CSP devices have
| a backside coating which protects the top of the chip from most
| light, which leaves the majority of the photosensitivity to the
| edges of the device (or, reflections to the underside).
|
| Some do, but in my view that's largely a design flaw rather
| than an issue endemic of all WLCSP devices. Also depends on the
| type of device you're building. Most basic digital logic,
| processors, and power parts shouldn't have meaningful issues
| with light. The problem usually is band gap or oscillator light
| sensitivity, which can be alleviated by chip layout changes.
| tallanvor wrote:
| I can't find a link now, but I remember a story about AT&T (I
| think) proudly showing off their new digital switching technology
| recently installed at an exchange and having the system crash
| when the flashes were strong enough to erase the EEPROMs they
| used in the system.
| DamonHD wrote:
| Erasing an EPROM typically took ~20 minutes of fairly intense
| UV, so that seems unlikely as-is.
| lambda wrote:
| The amount of exposure to reliably fully erase it, and the
| amount to flip one bit, are likely different. Flip the wrong
| bit and you can easily cause a crash. Yes, if you wanted to
| be sure to clear every bit you'd need that 20 minutes of
| exposure, but I wouldn't be surprised if flipping a single
| bit or a few of them was much easier.
| anonymousiam wrote:
| Two different effects being confused here. The EPROMs had a
| transparent window to the whole die. Bright flashes of
| light could disrupt the normal reading of memory, without
| permanently changing it. The sticker covering the window
| (usually with a description and version of the firmware)
| served multiple purposes.
| DamonHD wrote:
| Transient disruption of normal reads seems plausible to
| me. Any sort of erasure by flashes of light (visible or
| UV) that did not injure the humans, much less so!
| sidewndr46 wrote:
| The story as told is definitely made up as you can't erase an
| EEPROM with UV light. It's electrically erasable.
|
| If you meant 'EPROM' the story is almost certainly made up as
| the same company that sold you the EPROM sold you the sticker
| to put over the window.
| geerlingguy wrote:
| Every even numbered Pi model had some kind of interesting quirk
| requiring a hardware change to 'fix': - Pi 2 had
| the camera flash reboot issue - Pi 4 had improperly
| implemented USB-C charging circuit, causing many PD adapters to
| not power it[1]
|
| (I still have and use both of the original models -- the hardware
| flaw was only a problem in certain circumstances.)
|
| The Pi 5 has it's funky 5V / 5A requirement (though 5V / 3A works
| fine if you're not using high power USB accessories, if you have
| a decent power adapter), but it's otherwise not had any hardware-
| level odd quirk on the scale of Pi 2/4.
|
| So the question is: what will it be on the Pi 6?
|
| [1] https://hackaday.com/2019/07/16/exploring-the-raspberry-
| pi-4...
| klysm wrote:
| Have the compute modules had similar problems?
| geerlingguy wrote:
| They never made a CM2, but since they release the CMs after
| the main model B launch, they've always had time to fix a
| couple little hardware issues by the time the CM comes out.
| DamonHD wrote:
| Come on: "every" is clickbait and not meaningful here. My huge
| respect for you took a little knock.
| skrebbel wrote:
| How can an HN comment be clickbait? It's just fun nerdy
| banter. Obviously "both" is the better word choice here but
| then GP couldn't make the joke about number 6 could he?
| DamonHD wrote:
| It's an overhyped style which I suspect we get trained in
| when writing for payment.
|
| I've tried explicitly to avoid it, but usually the subs
| will rewrite all headings.
|
| Jeff shouldn't be doing it here: there is no sub to blame
| and we're not a mouth-breathing audience...
| skrebbel wrote:
| Like I said, the joke wouldn't work as well without the
| "every". This is a super common joke style. I used to
| tell people that every company I work at goes bust (I had
| worked at 3 companies at the time and they all went
| bust), so obviously I've got a Midas touch of bankruptcy
| and they shouldn't hire me. It's the same joke. It's not
| particularly original but it's also not "an overhyped
| style". It's just a joke.
| DamonHD wrote:
| Maybe I'm just oversenitised by "Just 3 special weird
| tricks to ..." rubbish. To me when the very first word is
| specious and there is no other 'joke incoming'
| clue/sidechannel/foreshadowing, my toes curl.
|
| Jeff: I may have misjudged your intent, but know that
| that style may not work on British technical pendants,
| obviously a valuable segment of your audience... %-P
|
| In penance I offer: every person who confuses correlation
| and causation dies...
| gopher_space wrote:
| Making declaratory statements and speaking in absolutes
| is a traditional way for engineers to ask questions and
| introduce topics in a peer-to-peer environment.
| geerlingguy wrote:
| Not sure what to say to that. But I'm glad you still have a
| little respect left :)
| georgemcbay wrote:
| this entire thread is full of people that must be a blast at
| parties.
| skrebbel wrote:
| Jao nao e ja jao YOLO ja nao!
| itishappy wrote:
| Fun fact: semiconductor effects are often reversible! A light
| emitting diode is an inefficient photovoltaic panel, and vice
| versa. This is relevant here because the same effect that allows
| you to stimulate the junctions using high intensity IR light
| happens in reverse: a stimulated junction emits IR light which
| can be detected through a thin enough package. With the right
| camera you could in theory take a video of specific junctions
| activating on chip. Efficiency makes this difficult in practice.
| I don't know how many photons you get per junction per clock
| cycle but it's not many, and those photons still need to make
| their way out of the package and be picked up by your sensor. I
| suspect getting a useful signal involves seriously overvolting
| the chip and/or underclocking it, so I'm not sure how
| "functional" of a test it would be.
|
| Wish I could remember the name of the company that was working on
| commercializing this...
| diggan wrote:
| > Fun fact: semiconductor effects are often reversible! A light
| emitting diode is an inefficient photovoltaic panel, and vice
| versa
|
| Another fun example: Manually rotating a DC motor produces
| current! Might make sense if you start out with generators I
| suppose, but as someone who used a DC motor "the other way"
| first, it was kind of counter-intuitive.
| ryoshu wrote:
| A speaker is an inefficient microphone and vice-versa.
| itishappy wrote:
| Examples off the top of my head include:
|
| * Electromagnetism (motors/generators)
|
| * Photoelectricity (LEDs/PVs)
|
| * Thermoelectricity (TEGs/Peltier coolers)
|
| * Piezoelectricity (crystal oscillators)
|
| Anybody got others?
| skrebbel wrote:
| In case the author reads HN, I just wanted to share that I was
| rather irked by the writing style, the way it adds all kinds of
| weird irrelevant bits of info that don't actually clarify
| anything (eg "the same phenomenon Einstein won a Nobel Prize for
| explaining") and ways to make things sound more spectacular than
| they are (eg "Blu-Tack (yes, really)" or the whole story about
| "community trust").
|
| I read on your about page that you use LLMs to assist your
| writing. Consider this comment a suggestion to depend on them
| less, or at least be more critical with their output. I've never
| been so frustrated reading a blog post as when I read yours as I
| flashed from interest to annoyance and back again many times.
| gedy wrote:
| I do agree that "assisted writing" is going to get old fast.
| Though your comment did made me think of as an alterative to
| chatting with LLMs, AI could be used to present search results
| on a particular topic in whatever format you prefer. E.g. these
| breezy writeups, tiktok style clips, youtube, podcast, "just
| the facts", etc. Different strokes and all that.
|
| As long as it's clear it's the machine or UI, I don't mind LLM
| output that much.
| KennyBlanken wrote:
| If I want to read LLM output, I'll type some input into one.
| I don't come to HN to get linked to shitty slightly-massaged
| LLM crap.
| tedunangst wrote:
| Conclusion seems rather forced. Like if trends continue, in ten
| years you will 1024 babies.
| jdbs_alter_ego wrote:
| Ugh, this article smells of AI slop.
|
| For starters the "jdb" "forum user" (with a Raspberry Pi Engineer
| tag - i.e. an employee) never claimed to have tested the board
| with any sort of Samsung camera.
|
| The actual post referencing Samsung is here:
| https://forums.raspberrypi.com/viewtopic.php?f=28&t=99042#p6... -
| which has a couple of broken nested quotes.
|
| And literally the next post has jdb's replication with a Canon
| compact handheld.
| mmastrac wrote:
| The author appears to have some LLM styles in other posts on
| the site (bolded list headers are the dead giveaway IMO):
|
| https://magnus919.com/2025/05/what-i-learned-about-agi-at-a-...
| RajT88 wrote:
| I am reminded of a strange issue I had with a DV Cam which I took
| on a "tiger cruise". The TC is where you visit your family aboard
| an aircraft carrier on the way back from a tour - in our case we
| rode the boat from Honolulu to San Diego.
|
| When on deck, the video would get scrambled every 3 seconds. It
| was a weird issue! I soon figured out it lined up with the sweep
| of the radar array - makes sense.
|
| Knowing I was dealing with radiation of some sort, I reasoned if
| I kept my phone angled so the battery (filled with heavy metals)
| between the radar array and magnetic heads, the video would no
| longer stutter every 3 seconds. Worked like a charm.
___________________________________________________________________
(page generated 2025-05-24 23:00 UTC)