The Xenon Death Flash: How a Camera Nearly Killed the Raspberry Pi 2 | Hacker News Reader

The Xenon Death Flash: How a Camera Nearly Killed the Raspberry Pi 2

magnus919.com

233 pointsDamonHD89 comments

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.

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...

Well then, can’t really fault the engineers if they told users about it. Fun hobby mystery and nobody got killed. 10/10.

> 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.

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.

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.

> 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.

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.

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.

Raspberry Pi themselves said they were prioritizing businesses over retail consumers at the time; businesses need stuff to sell to remain viable.

That’s all well and good, but Raspberry Pi had been positioned in the market as educational, entry-level, easy to understand and ideal for children learning Linux, Python, or electronics.

Perhaps some kids can circulate a list of those commercial products incorporating a Pi, and campaign to liberate and repurpose them. Win-win?

"campaign" lol. I can remember some of my youthful "campaigns" to liberate useful technology... I cant say I find them recommendable.

> 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

I remember placing stickers over EPROM windows to protect them from sunlight.

Deep deep archived memory that one...

Hehe.. remembered an optimum wavelength ~255nm (and indeed - Wikipedia says 253.7nm. Close enough :).

> sunlight would erase a chip in weeks

Been there, done that. When I wasn't in a hurry, I'd stick some EPROMs in a foam & put 'em under a window. Usually took a bit under 3 weeks. But no point trying in the midst of winter; probably works but could take months.

Loved those windowed ceramic packages. Especially microcontroller parts like (iirc) 87C52. Lovely patterns to have a look at with magnifier.

When I was a kid I used to spend hours exploring the surface of windowed ICs with my field microscope. I have a weird association of microchip architecture and the depictions of the surface of the “Death Star” in Star Wars. I think I used to imagine I was flying over the surface of the chip lol. I was slightly saddened by the electron microscopy of smaller node sizes as time went on, the features became more globby and a little less beautiful.

> 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.

So what should I buy instead of the RPi Zero 2 W, that's faster, cheaper, and better?

Ah, there it is. As a long-time Pi lore aficionado (is there such a thing? or am I just obsessed with a company that the CEO amusingly describes as "the other fruit computer company"?) in any thread that gets traction there's inevitably a screed posted along these lines:

* "I'm mad because there's not an open source hardware/software/gpu/schematics/BOM" so I can't hypothetically make a clone of it

* If (1) above is not the motivation, then it's because there's some specific use-case that doesn't work that the rage-post precipitates, and crucially - includes zero links to bug reports or a log of efforts that the OP has attempted

* "All the designers are idiots because minor fault X is indicative of systemic failure Y" - with no supporting evidence

* General assertions that all these faults are catastrophic and should bankrupt the company (often conflated with the Foundation, which is a completely separate legal entity)

There's been about 80 million units sold so far. They must be doing something right.

Disclaimer: I own RPI.L stock. It's one of the few tech stocks on the LSE that have actually performed OK and not tanked since IPO.

When you make something that will be mass produced 80 million times, you have a fundamental duty as an engineer to absolutely minimize the amount of negative externalities that will be experienced by people that come into contact with the surface that you have inflicted upon the world.

“Real” engineers understand this and that is why they are often seemingly irrational about their selective attention to detail.

Hacks and noobs are just unintentionally dumping plane loads of gum wrappers over our cities, nominally increasing human misery by tiny amounts without even realizing it… but in a population of billions, and more transistors than grains of sand on the planet, the overall effect is cumulative and significant.

That’s why people that understand their civic responsibility to do their job to the best of their ability look upon hacks and noobs with concern or sometimes active hostility.

Unfortunately, people that understand the responsibility aspect of engineering are few and far between. Hack together whatever you want, and Have fun doing it… but if your actions are going to create millions or billions of objects that millions or billions of people are going to somehow interact with or be exposed to the effect of on a daily basis, you have a deep and fundamental responsibility to make sure that those interactions are at the very least completely and utterly benign. This applies to software as well as hardware.

Introducing even a tiny spark of misery into the world that will be experienced millions or billions of times makes you a world class asshole that has actively contributed to making the world a shittier place in a significant way. It’s like you just dumped a c130 load of gum wrappers over a city from high altitude.

Doesn't the article say, in the second paragraph, "...he’d stumbled onto something unprecedented."?

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!

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.

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.

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!

> 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...

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.

I'm not sure about onsemi's openness, but I found the public datasheet for the U16 power regulator affected (NCP6343) with one search [1]. As the article explained, the Broadcom SoC has nothing to do with this fault.

I don't think "makers" should be brought into this - to me, "makers" include individuals who may not have any formal engineering education just putting ideas together.

Of course it's a different story for actual companies selling a product such as Raspberry Pi - the engineering standard should rightfully be higher.

[1] https://www.onsemi.com/download/data-sheet/pdf/ncp6343-d.pdf

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.

Maybe it’s just been the luck of the draw, but I’ve had the issue pop up almost every time I have built something with an WLCSP that I wasn’t sure would be potted. It’s usually NBD though, since normally things go in cases. In adversarial or critical situations a drop of (soft) potting glue does the trick.

> Most basic digital logic, processors, and power parts shouldn’t have meaningful issues with light.

Depends... if you have an input that isn't driven externally (tri-state or nc), and there's just a weak pull-up or -down on the pin, you could have issues. An unexpected reset here, a bitflip there...

Also there's high-impedance ADC inputs on some parts. Wouldn't take much to send readings waayy out of spec.

Note that affected signal might be inside the IC (not going to an IO pin). More likely to be driven though (low-impedance).

Also EPROM? Erasable programmable ROM that is wiped with UV light.

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.

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.

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.

To contrast, I found that tidbit about Einstein helpful, as it took my memory more promptly to when I studied it in physics classes.

I enjoyed the post more as a story more than as a report.

Hard disagree. I enjoyed reading every word.

One of the things I'm not looking forward to with people "just throwing it through an LLM for a final pass" is the loss of individual voice.

Everything is starting to sound the same, and it's becoming monotonous

I agree. Every time I read "This highlights" or "This contrasts with" I want to puke.

The initial part was fine but when it got to the conclusion it was incredibly monotonous.

Another classic hardware glitch: iPhones Are Allergic to Helium [1]

[1] https://www.ifixit.com/News/11986/iphones-are-allergic-to-he...

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.

It was documented in Apple's user guide.

Really? If that happened before the publicised discovery, it is a very impressive example of attention to detail.

> Really?

Really. It's in the article linked.

> If that happened before the publicised discovery, it is a very impressive example of attention to detail.

The article seems to imply it was, but I don't know timelines because links are broken and I don't feel like doing archaeology. It is a known issue with that MEMS component before it made its way into the iPhone, so I don't find it very impressive. I don't know about Apple in particular, but it is very standard for electronics user manuals and spec sheets to list operating envelopes and known issues and limitations exhaustively.

And here's an excellent followup video on helium sensitivity:

https://www.youtube.com/watch?v=vvzWaVvB908

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...

Have the compute modules had similar problems?

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.

Come on: "every" is clickbait and not meaningful here. My huge respect for you took a little knock.

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?

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...

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.

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...

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.

Not sure what to say to that. But I'm glad you still have a little respect left :)

Lots left! B^>

this entire thread is full of people that must be a blast at parties.

Jåo nåo e ja jåo YOLO ja nåo!

Hey, my parties are good! %-P

Pi 3 had issues with power voltage, eventually solved by special 5.1V adapters. All models has microSD longevity issues. PoE HATs had issues too.

One thing common to all models of Pi is that the onboard power circuits are either rather simplistic, or missing altogether. I think I saw somewhere that this may have to do with EU/UK regulations that otherwise forbid the bare board sold as a consumer product. Anyone read/heard similar?

Pi 1 had its share of hardware issues too, though - the LAN9512 1.8V regulator issue comes to mind, for instance, as well as USB port brownouts.

Does anybody remember when the very first Pi was delayed due to an Ethernet magnetics issue? IIRC they needed a jack with integrated magnetics but populated a wrong part. How far they’ve come since then!

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...

> 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.

A speaker is an inefficient microphone and vice-versa.

I once connected a microphone to the audio output by mistake. You can imagine how confused I was when the microphone started playing music.

Examples off the top of my head include:

* Electromagnetism (motors/generators)

* Photoelectricity (LEDs/PVs)

* Thermoelectricity (TEGs/Peltier coolers)

* Piezoelectricity (crystal oscillators)

Anybody got others?

> Piezoelectricity

Ceramic capacitors can have similar issues: apply voltage, part warps a tiny bit. @ the right frequencies some (mechanical) resonance effects might come into play. Yay! But I have a hard time imagining this to be a real-world problem.

Edit: "microphony" or "microphonics"

https://en.wikipedia.org/wiki/Microphonics

Just an idea: coil whine might be reversible too. Vibrate coil, get some (noise in) inductor current.

Oh yeah: don't yell too loud at your (spinning) harddrives.

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.

IBM memory chips - great story, which I copied into this comment: https://news.ycombinator.com/item?id=25279964

I had same issue with fancy translucent cover for my hearing aids. Sunlight at certain angles and flashes caused noise. Nobody believed me.

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.

HN thread at the time https://news.ycombinator.com/item?id=9015663

Thank you!

    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

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.

Post-silicon debug of flip-chip parts is sometimes done by shining a laser on the chip at a very specific spot and detecting backscatter from the laser spot to determine if a transistor is on or not. If you turn the laser power up, you can switch specific transistors open or closed. Semiconductors in general are pretty sensitive to light, which is why they are usually packaged in a way that keeps them dark during operation.

This also happened to me. I guess it was the late 1980s.

I was programming UV erasable microcontrollers in quartz-windowed ceramic packages. Once I had the whole multi-processor distributed system up and running, I snapped a photo with my flash (film) sports camera.

Everything crashed! I also had to repeat the process reliably a couple of times before I was convinced it was the flash that caused it.

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.

Erasing an EPROM typically took ~20 minutes of fairly intense UV, so that seems unlikely as-is.

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.

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.

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!

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.

I used to use xenon flashes to calibrate latencies to calibrate data streams. I had a few different SDR devices hooked up to consumer hardware, and a high resolution/accuracy (50ns) time device I could control a xenon flash with. I’d trigger the xenon flash and basically just inject the flash in the data.

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.

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-...

Conclusion seems rather forced. Like if trends continue, in ten years you will 1024 babies.

Reply on news.ycombinator.com