Xenon Death Flash: Der Vorfall, bei dem eine Kamera den Raspberry Pi 2 beinahe lahmlegte

 (magnus919.com)
1 Punkte von GN⁺ 2025-05-26 | 1 Kommentare | Auf WhatsApp teilen
  • Es wurde ein ungewöhnliches Verhalten entdeckt: Jedes Mal, wenn ein Raspberry Pi 2 dem Xenon-Blitz einer Kamera ausgesetzt wurde, schaltete sich das Gerät aus.
  • Ursache dieses Phänomens ist ein photoelektrischer Effekt im Stromregelungs-Chip (U16) mit WL-CSP-Packaging, wenn Licht in den Chip eindringt.
  • Experimente der Community zeigten, dass LED-Blitze kein Problem verursachen, während Xenon-Blitze oder Laserpointer Fehler auslösen.
  • Die sofortige Lösung bestand darin, den U16-Chip mit undurchsichtigem Material abzudecken; später wurde das Schaltungsdesign durch eine Hardware-Revision grundlegend verbessert.
  • Der Vorfall ist ein typisches Beispiel für die Anfälligkeit ultrakompakter Elektronik gegenüber Lichtstörungen und für die Bedeutung gemeinschaftlicher Zusammenarbeit.

Einleitung: Der seltsame Bug, den ein Kamerablitz auslöste

  • Im Februar 2015 erlebte der langjährige Raspberry-Pi-Community-Veteran Peter Onion beim Fotografieren eines neuen Raspberry Pi 2 ein Problem: Immer wenn der Kamera-Blitz auslöste, schaltete sich der Pi sofort aus.
  • Da das Phänomen wiederholt auftrat und kein Zufall sein konnte, teilte er den Vorfall im Raspberry Pi Forum.
  • Die Community begann sofort mit Tests unter Verwendung verschiedener Kameras und Lichtquellen und stellte fest, dass LED-Blitze unproblematisch waren, Stromausfälle aber nur bei Xenon-Blitzen auftraten.

The Hunt for the Vulnerable Component

  • Die eigentliche Ursachenforschung bestand darin herauszufinden, welches Bauteil des Raspberry Pi 2 verwundbar war.
  • Es wurden Methoden ausprobiert, etwa das Abdecken des Hauptprozessors mit Blu-Tack (eine Art Klebemasse).
  • Als einige Community-Mitglieder das Gerät verkehrt herum testeten und es dann nicht auf den Blitz reagierte, wurde bestätigt, dass es sich um ein lichtbezogenes Problem handelte.
  • Durch weitere Experimente wurde der U16-Chip zwischen USB-Anschluss und HDMI als Hauptursache identifiziert; allein das Abdecken dieses Chips beseitigte das Problem vollständig.

Die Physik hinter dem „Xenon Death Flash“

  • Der U16-Chip verwendet eine Wafer-Level Chip Scale Packaging (WL-CSP)-Struktur, bei der der Silizium-Die ohne schützende Verkapselung direkt auf der Platine freiliegt.
  • Bei Einwirkung einer externen hochintensiven Lichtquelle tritt ein photoelektrischer Effekt auf, bei dem hochenergetische Photonen im Chip unerwartete Elektronenströme verursachen.
  • Dadurch wird die Spannungsregelung beeinflusst, was zum sofortigen Shutdown des Pi 2 führt.
  • LED-Blitze sind harmlos, weil ihre Photonenenergie nicht ausreicht; Xenon-Blitze oder Laserpointer besitzen jedoch genug Energie, um die Schwachstelle auszulösen.

Bereits zuvor bekannte Probleme mit Lichtstörungen

  • Schon vor dem Raspberry Pi 2 gab es ähnliche Fälle von Anfälligkeit für Lichtstörungen.
  • Ein bekanntes Beispiel ist ein 12 Jahre früherer Handy-Prototyp, dessen CSP-Verstärkerchip durch einen Kamerablitz fehlfunktionierte.
  • 1997 störte in den USA im Kernkraftwerk Haddam Neck ein Blitzlichtfoto den EPROM-Chip eines Feueralarm-Panels und aktivierte sogar das Gasauslasssystem.
  • Das zeigt, dass elektronische Bauteile mit zunehmender Miniaturisierung und stärkerer Freilegung anfälliger gegenüber der Lichtumgebung werden.

Lösungsansatz: Von Blu-Tack bis zur Designverbesserung

  • Als sofortige Gegenmaßnahme wurde empfohlen, den U16-Chip mit undurchsichtigem Material (Blu-Tack, Isolierband, Kitt) abzudecken.
  • Dadurch ließ sich die Schwachstelle durch physisches Blockieren des Lichts vorübergehend beheben.
  • Später wurde in der zweiten Jahreshälfte 2015 beim Raspberry Pi 2 Rev 1.2 die Stromversorgungsarchitektur zusammen mit dem Chip auf eine BCM2837-basierte Lösung umgestellt, wodurch die Lichtanfälligkeit grundlegend beseitigt wurde.
  • Frühere Pi-Modelle waren aufgrund ihrer Bauweise von diesem Problem nicht betroffen.

Was die Schwachstelle über moderne Elektronik aussagt

  • Die Schwachstelle des Pi 2 zeigt, dass das Streben nach extremer Miniaturisierung und niedrigen Kosten unerwartete neue Schwachstellen schaffen kann.
  • Herkömmliche Tests elektronischer Geräte berücksichtigen meist nur elektromagnetische Störungen, während Prüfungen auf Lichtstörungen unzureichend sind.
  • Technologien wie WL-CSP sparen Platz und Kosten, bringen aber Schwächen beim Schutz mit sich.
  • Sie deutet auch darauf hin, dass ungewöhnliche Nutzungssituationen wie Blitzfotografie neue Probleme verursachen können, die zuvor nicht bedacht wurden.

Das Vermächtnis dieses „liebenswerten Bugs“

  • Die Raspberry Pi Foundation bezeichnete den Bug als den „liebenswertesten Bug aller Zeiten“ und legte das Problem transparent offen.
  • Der Vorfall etablierte sich zudem als lehrreiches Beispiel aus der Elektronik, an dem sich der photoelektrische Effekt im Alltag nachvollziehen lässt.
  • Darüber hinaus trug er dazu bei, das Bewusstsein für Lichtstörungen im Halbleiterdesign zu schärfen.
  • So speziell der Fall auch ist: Er verdeutlicht branchenweit die Notwendigkeit vielfältigerer Prüfprozesse.

Lehren für die Gegenwart

  • Diese Geschichte mahnt mit Blick auf Hardware-Sicherheit und die Nebenwirkungen aggressiver Miniaturisierung zur Vorsicht.
  • Eingebettete Geräte im IoT-Zeitalter könnten ähnliche Schwachstellen wie der Pi 2 potenziell ebenfalls aufweisen.
  • Interessante Bugs entstehen in der Regel an den Schnittstellen eigentlich nicht verwandter Technologien.
  • Der Fall beweist, wie wichtig die Kraft kollektiver Problemlösung in Communities wie der Raspberry-Pi-Community ist.
  • Er zeigt exemplarisch, dass Neugier und Zusammenarbeit selbst die seltsamsten Probleme lösen können.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-26
Hacker-News-Kommentare
  • Ich möchte darauf hinweisen, dass die Lichtempfindlichkeit von WLCSP-Bauteilen nicht erst von der Community „entdeckt“ wurde. In WLCSP-Datenblättern ist ausdrücklich vermerkt, dass diese Bauteile lichtempfindlich sind, und es gibt dort auch Daten zu den Auswirkungen von Licht auf die Bauteile. Das war in der Branche schon bekannt, seit WLCSP erstmals aufkam, und jeder verantwortungsbewusste Ingenieur sollte das zwingend als Designfaktor berücksichtigen. Siliziumchips sind letztlich wie kleine Solarpanels aufgebaut und reagieren daher selbstverständlich auf Licht. CMOS-Bildsensoren sind im Grunde nur Speicherchips, die gezielt beleuchtet werden, und WLCSP-Chips sind faktisch Siliziumchips ohne nennenswerte Verpackung. All das ist seit Langem bekannt. Auch dass man Transistoren durch Decapping freilegt und dann als Lichtsensoren oder Solarzellen nutzen kann, ist eine alte Geschichte, und frühe Fototransistoren wurden ebenfalls in Gehäusen mit Fenster verbaut, statt das Licht abzuschirmen. Wenn man WLCSP direkt auf einer ungeschützten PCB verbaut und Lichtempfindlichkeit dann ein Problem ist, würde ich sagen, der Designer ist entweder unerfahren oder braucht engere Aufsicht. Vor einem breiten Einsatz eines Bauteils das Datenblatt zu lesen und den Aufbau von Siliziumchips sowie die Prinzipien von Halbleiterübergängen zu verstehen, gehört zu den Grundlagen des Ingenieurwesens. Der Artikel selbst war interessant, aber der belehrende Ton und die ständige Zusammenfassungsweise wirkten stark von LLMs oder AI beeinflusst
    • Im Artikel wurde nicht behauptet, dass die Lichtempfindlichkeit von WLCSP-Bauteilen erstmals von der Community entdeckt worden sei. Es gibt dort einen Abschnitt „This Wasn’t Actually Unprecedented“, in dem frühere Fälle und die Ursache erwähnt werden, inklusive Link zu einem einschlägigen Artikel. Neu war hier tatsächlich das Lichtempfindlichkeitsproblem des Raspberry Pi 2; dass WLCSP-Bauteile an sich lichtempfindlich sein können, war bereits bekannt. Die meisten PCBs sind für Verbraucher nicht sichtbar, deshalb ist das Problem in der Praxis nur selten aufgefallen. Die Ansicht, ein Designer müsse unerfahren sein, wenn ungeschützte WLCSP-Bauteile in einer Umgebung eingesetzt wurden, in der Lichtempfindlichkeit inakzeptabel ist, halte ich für übertrieben. Das war ein sehr seltener Fall, bei dem eine extrem starke und spezielle Lichtquelle wie ein Xenon-Blitz mit einer exponierten PCB zusammenkam, und ich könnte mir vorstellen, dass selbst das Datenblatt des betreffenden Bauteils das nicht ausdrücklich erwähnt hat
    • Genau dieselbe Debatte gab es schon vor 10 Jahren. Im damaligen Datenblatt, das Raspberry Pi verwendete, stand: „Schutzmaßnahmen gegen Lichtempfindlichkeitsschaltungen, wie sie in der einschlägigen Literatur erwähnt werden, sind in der Praxis kein Problem. Silizium ist nur für Licht mit langen Wellenlängen transparent. Solches Licht ist in den typischen Einsatzumgebungen von WLCSP selten.“ https://web.archive.org/web/20150210111428/https://www.fairchildsemi.com/application-notes/AN/AN-5075.pdf
    • Ich kann nachvollziehen, dass man es fragwürdig findet, nackte Chips auf eine ungeschützte Platine zu setzen und dann normales Verhalten zu erwarten. Früher gab es auch Fälle, in denen Kunststoffverkapselungen wegen eines zu geringen Carbon-Black-Anteils lichtempfindlich waren, und manche ältere Bauteile waren sogar in braunen Kunststoffgehäusen verpackt, die nicht vollständig opak waren. https://electronics.stackexchange.com/questions/217423/ics-chips-are-typically-packaged-in-what-material
    • Ich glaube nicht, dass alle WLCSP-Bauteile tatsächlich eine ausgeprägte Lichtempfindlichkeit haben. Die meisten CSP-Bauteile sind oben auf dem Die beschichtet, sodass sich das Problem eher auf Randbereiche oder reflektiertes Licht beschränken dürfte. Tatsächlich problematisch sind wohl nur einige wenige Bauteile, und in solchen Fällen würde ich eher von einem Designfehler sprechen. Je nach Gerätetyp kann das variieren, aber bei allgemeiner Logik, Prozessoren oder Power-Bauteilen gibt es kaum relevante Lichtempfindlichkeit; betroffen sind eher band gap- oder Oszillatorschaltungen. In solchen Fällen lässt sich das Problem oft durch ein geändertes Layout abmildern
    • Heute habe ich wieder etwas Neues gelernt! Ich habe solche Packages schon mehrfach verwendet und sie fast wie BGA behandelt. Für mich war das einfach eine Option, wenn etwas Kleineres als QFN gebraucht wurde oder nur dieses Bauteil verfügbar war, und man eben in Kauf nahm, die Pins nicht mit bloßem Auge prüfen zu können. Wenn es nicht gerade um High-Speed-Signale oder RF geht, achtet man auf den footprint oft nicht besonders, und wenn eine Platine viele Bauteile hat und das Datenblatt lang ist, kann man so etwas leicht übersehen. Wenn man sich daran gewöhnt, nur die wichtigen Stellen herauszupicken, rutschen Details schnell durch; dieser Fall zeigt aber, dass bei Geräten für die Massenproduktion eine sorgfältige Prüfung umso wichtiger ist
  • Falls der Autor HN liest, würde ich gerne rückmelden, dass der Text immer wieder mit nicht wesentlichen Zusatzinformationen angereichert war, die nicht zur Kernerklärung beitrugen und eher störten als neugierig machten, etwa „das Phänomen, für das Einstein den Nobelpreis bekam“, „Blu-Tack (wirklich)“ oder die Geschichte mit dem Vertrauen der Community. Auf der About-Seite des Autors steht, dass LLMs beim Schreiben eingesetzt werden; ich würde daher anregen, sich etwas weniger auf solche Hilfswerkzeuge zu verlassen oder die Ergebnisse kritischer zu überarbeiten. Ich habe selten einen Blogpost gelesen, der abwechselnd so interessant und so nervig war
    • Mir haben die Einstein-Infos eher geholfen, schnell wieder an das anzuknüpfen, was ich im Physikunterricht gelernt hatte. Dadurch fühlte sich der Text weniger wie ein Bericht und mehr wie eine Geschichte an, was ihn für mich unterhaltsamer machte
    • Das ist sicher Geschmackssache, aber ich finde es schade, dass bei LLM-Ergebnissen der individuelle Schreibstil von Menschen immer mehr verschwindet und alles nur noch einmal „zum Schluss durch ein LLM gejagt“ wird. Wenn jeder Text in demselben Tonfall wiederholt wird, wird es schnell langweilig
    • Wenn sich Formulierungen wie „This highlights“ oder „This contrasts with“ ständig wiederholen, wird der Text wirklich schwer lesbar. Der Einstieg war noch okay, aber ab dem Fazit wirkte es repetitiv und unerquicklich
    • Ich fand jeden Teil des Artikels interessant
    • Ich stimme zu, dass man „AI-unterstütztes Schreiben“ vermutlich schnell überhaben wird. Andererseits könnte es besser sein, wenn AI statt LLM-Chat Suchergebnisse je nach Thema in der gewünschten Form als Dokument aufbereitet — etwa als kurze Zusammenfassung, YouTube-Clip, Podcast oder Faktenliste. Wenn klar erkennbar ist, dass das Ergebnis von einer Maschine oder UI stammt, stört mich der LLM-Output an sich viel weniger
  • Ein anderer Hardware-Bug, an den mich das erinnert, ist die „Helium-Allergie des iPhone“ https://www.ifixit.com/News/11986/iphones-are-allergic-to-he...
    • Das Interessante am Helium-Fall war, dass damals selbst MEMS-Hersteller die Auswirkungen verschiedener Umgebungs­gase noch nicht tiefgehend untersucht hatten. Für Techniker im Feld war das noch leichter zu übersehen, und wenn man mit MEMS-Fertigungsprozessen nicht vertraut war, erst recht. Die Hersteller verwendeten bei der Erstkalibrierung validierte Gasmischungen, daher war es für sie wohl keine große Überraschung, aber für normale Ingenieure war es ein eher unsichtbarer Aspekt
    • Dazu gibt es auch ein gutes Folgevideo zur Helium-Empfindlichkeit https://www.youtube.com/watch?v=vvzWaVvB908
  • Jedes Raspberry-Pi-Modell mit gerader Nummer hatte irgendeinen interessanten Hardwarefehler
    • Pi 2: Reboot-Problem durch Kamerablitz
    • Pi 4: Fehler in der USB-C-Ladeschaltung (bei mehreren PD-Adaptern keine Stromversorgung) https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4... Ich besitze sowohl das ursprüngliche Pi 1 als auch das Pi 4, und die Defekte waren nur unter bestimmten Bedingungen ein Problem. Das Pi 5 hat — abgesehen davon, dass es 5V/5A braucht (mit einem guten Adapter läuft es meist auch mit 5V/3A ordentlich) — keine so gravierenden Hardwareprobleme wie die Modelle 2 und 4. Deshalb fragt man sich natürlich, was beim Pi 6 passieren wird
    • Erinnerst du dich, dass sich die Veröffentlichung des ersten Pi wegen eines Problems mit dem Ethernet-Magnetics verzögert hatte? Es hätte eine Buchse mit integrierten Magnetics gebraucht, stattdessen wurde das falsche Bauteil verwendet. Daran sieht man erst, wie weit man seitdem gekommen ist
    • Beim Pi 3 gab es ein Spannungsproblem, das mit einem speziellen 5,1V-Adapter gelöst wurde. Bei allen Modellen gab es Haltbarkeitsprobleme mit microSD, und auch das PoE HAT hatte Probleme. Allen Raspberry-Pi-Modellen gemeinsam ist, dass die integrierte Stromversorgung auf dem Board übermäßig simpel oder praktisch nicht vorhanden ist. Ich meine mich auch an ein Gerücht zu erinnern, dass nackte Boards wegen britischer/EU-Vorschriften in manchen Fällen nicht als Consumer-Produkt verkauft werden dürften
    • Auch Pi 1 hatte Hardwarefehler, etwa Probleme mit dem 1,8V-Regler des LAN9512 oder Brownouts an den USB-Ports
    • Ich frage mich, ob die Compute-Module-Serie auch solche Probleme hatte
    • Dieses Aufbauschen mit Formulierungen wie „alle“ finde ich wenig sinnvoll, deshalb war ich etwas enttäuscht — gerade weil ich die Person sonst sehr schätze
  • Ich finde es faszinierend, dass sich die Eigenschaften von Halbleitermaterialien oft umkehren lassen. Eine LED ist ein ineffizientes Solarpanel, und umgekehrt gilt das genauso. Der interessante Punkt hier ist, dass man bei Bestrahlung einer Sperrschicht mit einer starken IR-Lichtquelle die angeregte Junction im Gegenzug IR-Strahlung emittieren lassen kann, und wenn das Package dünn genug ist, lässt sich das mit einer Kamera erfassen. Theoretisch könnte man also die Aktivierung bestimmter Junctions bildlich nachverfolgen. Praktisch ist das allerdings nicht effizient, das Signal ist schwach, und man müsste den Chip womöglich deutlich übervolten oder untertakten. Ob das in der Praxis testbar genug wäre, ist fraglich. Mir fällt gerade der Name der Firma nicht ein, die so etwas kommerzialisieren wollte
    • Ein anderes schönes Beispiel ist, dass ein DC-Motor Strom erzeugt, wenn man ihn mit der Hand dreht. Wenn man bedenkt, dass Generator und Motor auf demselben Prinzip beruhen, ist das eigentlich selbstverständlich, aber wenn man zuerst nur von Motoren her denkt, wirkt es überraschend paradox
  • Das erinnert mich an einen Fall, in dem der Cache einer SPARC-CPU durch radioaktiven Zerfall von Verunreinigungen im Chip-Package beschädigt wurde. In meinem ersten Job habe ich wegen dieses Problems ziemlich viel Zeit verloren
  • Ich erinnere mich, dass ich dasselbe Problem mit einer transparenten Kunststoffabdeckung für Hörgeräte hatte. Bei Sonnenlicht oder Blitzlicht aus einem bestimmten Winkel trat Rauschen auf, aber niemand wollte mir glauben
  • Ich war einmal auf einem Flugzeugträger bei einer „Tiger Cruise“ und habe dort eine DV-Cam benutzt. Auf dem Deck wurde das Video alle drei Sekunden seltsam gestört. Das stimmte exakt mit dem Sweep-Intervall des Radars überein. Ich war mir sofort sicher, dass Strahlung die Ursache war, und als ich den Winkel so anpasste, dass der Handy-Akku (mit seinen Schwermetallen) zwischen Radar und Magnetkopf lag, verschwand das Problem mit den Aussetzern vollständig
  • Hier ist der Link zur damaligen HN-Diskussion https://news.ycombinator.com/item?id=9015663
  • Das nachträgliche Debugging von Flip-Chip-Halbleitern ist auch möglich, indem man mit einem Laser auf bestimmte Punkte zielt und aus dem reflektierten Licht den Ein-/Aus-Zustand eines Transistors ableitet. Erhöht man die Laserleistung, kann man bestimmte Transistoren sogar direkt öffnen oder schließen. Halbleiter sind von Natur aus lichtempfindlich; deshalb werden Chips normalerweise in opake Packages eingeschlossen, um sie davor zu schützen