Xenon Death Flash : l’incident où un appareil photo a failli presque détruire le Raspberry Pi 2

• Une anomalie a été découverte : le Raspberry Pi 2 s’éteignait chaque fois qu’il était exposé au flash au xénon d’un appareil photo
• La cause de ce phénomène était un effet photoélectrique se produisant lorsqu’une lumière entrait dans la puce de régulation d’alimentation (U16) utilisant un packaging WL-CSP
• Les expériences de la communauté ont montré que les flashs LED ne posaient aucun problème, mais que les flashs au xénon ou les pointeurs laser provoquaient l’erreur
• La solution immédiate a consisté à recouvrir la puce U16 d’un matériau opaque, puis une révision matérielle a permis d’améliorer fondamentalement la conception du circuit
• Cet incident constitue un cas emblématique montrant à la fois la vulnérabilité des appareils électroniques ultra-compacts aux interférences lumineuses et l’importance de la collaboration communautaire

---

Introduction : l’étrange bug provoqué par le flash d’un appareil photo

• En février 2015, Peter Onion, vétéran de la communauté Raspberry Pi, a constaté lors d’une prise de vue d’un nouveau Raspberry Pi 2 que la carte s’éteignait instantanément chaque fois qu’un flash se déclenchait
• Comme le phénomène se reproduisait, il a conclu qu’il ne s’agissait pas d’un hasard et a partagé l’information sur le forum Raspberry Pi
• La communauté a immédiatement commencé à tester avec plusieurs appareils photo et sources lumineuses, découvrant que les flashs LED ne causaient aucun souci, alors que seuls les flashs au xénon entraînaient une coupure d’alimentation

La chasse au composant vulnérable

• L’identification de la cause a véritablement commencé par la recherche du composant vulnérable sur le Raspberry Pi 2
• Des méthodes comme recouvrir la puce du processeur principal avec du Blu-Tack (pâte adhésive) ont été essayées
• Lorsque certains membres de la communauté ont retourné l’appareil pendant les tests, son absence de réaction au flash a confirmé qu’il s’agissait d’un problème lié à la lumière
• Des expériences supplémentaires ont permis d’identifier la puce U16 située entre le connecteur USB et le port HDMI comme cause principale ; le simple fait de la masquer faisait complètement disparaître le problème

La physique derrière le « Xenon Death Flash »

• La puce U16 utilisait une structure Wafer-Level Chip Scale Packaging (WL-CSP), dans laquelle le die en silicium est exposé directement sur la carte sans capsule de protection
• Lors d’une exposition à une source lumineuse externe de forte intensité, un effet photoélectrique se produisait, des photons à haute énergie provoquant des flux d’électrons inattendus à l’intérieur de la puce
• Cela perturbait le circuit de régulation de tension, entraînant l’arrêt immédiat du Pi 2
• Les flashs LED étaient inoffensifs faute de photons suffisamment énergétiques, tandis que les flashs au xénon ou les pointeurs laser disposaient d’une énergie suffisante pour déclencher cette vulnérabilité

Un problème d’interférences lumineuses déjà observé auparavant

• Avant même le Raspberry Pi 2, des cas similaires de vulnérabilité aux interférences lumineuses avaient déjà été identifiés
• Parmi les exemples marquants, on trouve un prototype de téléphone portable d’il y a 12 ans dont une puce amplificatrice CSP dysfonctionnait sous l’effet d’un flash d’appareil photo
• En 1997, à la centrale nucléaire de Haddam Neck aux États-Unis, une photo au flash a même perturbé une puce EPROM d’un panneau incendie, déclenchant jusqu’au système de décharge de gaz
• Cela montre que plus les composants électroniques sont miniaturisés et exposés, plus leur vulnérabilité à l’environnement lumineux augmente

Solutions : du Blu-Tack à l’amélioration de la conception

• Comme réponse immédiate, il a été recommandé de recouvrir la puce U16 d’un matériau opaque (Blu-Tack, ruban isolant, mastic)
• Le blocage physique de la lumière permettait de résoudre temporairement la vulnérabilité
• Plus tard, dans la seconde moitié de 2015, le Raspberry Pi 2 Rev 1.2 a modifié sa structure de gestion d’alimentation et sa puce sur une base BCM2837, supprimant fondamentalement cette vulnérabilité optique
• Les anciens modèles de Pi n’étaient pas affectés par ce problème en raison de leur architecture

Ce que cela révèle sur les vulnérabilités des appareils électroniques modernes

• La vulnérabilité du Pi 2 montre que la recherche d’une miniaturisation extrême et de coûts réduits peut créer de nouvelles failles inattendues
• Les tests des appareils électroniques traditionnels prennent surtout en compte les interférences électromagnétiques, tandis que les vérifications liées aux interférences lumineuses restent insuffisantes
• Des technologies comme le WL-CSP offrent des gains de taille et de coût, mais présentent des faiblesses du point de vue de la protection
• Cela suggère que des conditions d’utilisation anormales non anticipées (comme une photo au flash) peuvent provoquer de nouveaux problèmes

L’héritage d’un « bug adorable »

• La Raspberry Pi Foundation a qualifié ce bug de « bug le plus adorable de tous les temps » et a communiqué le problème en toute transparence
• Cet incident s’est imposé comme un exemple pédagogique en électronique permettant d’observer l’effet photoélectrique dans la vie réelle
• Il a également contribué à une meilleure prise de conscience des problèmes d’interférences lumineuses dans la conception des semi-conducteurs
• Très spécifique, il a néanmoins rappelé à l’ensemble du secteur la nécessité de diversifier les processus de validation

Leçon pour aujourd’hui

• Cette histoire alerte sur la sécurité matérielle et les effets secondaires d’une miniaturisation agressive
• Les appareils embarqués de l’ère IoT peuvent potentiellement présenter des vulnérabilités similaires à celle du Pi 2
• Les bugs les plus intéressants apparaissent généralement à l’intersection de technologies sans rapport apparent
• Elle démontre l’importance de la résolution collective de problèmes au sein de communautés comme celle de Raspberry Pi
• C’est un exemple marquant montrant que la curiosité et la collaboration peuvent résoudre même les problèmes les plus étranges

[GN⁺]

Commentaires sur Hacker News

• Je tiens à préciser que la photosensibilité des composants WLCSP n’a pas été « découverte » par la communauté. Les fiches techniques WLCSP indiquent déjà que ces composants sont photosensibles et fournissent des données sur l’effet de la lumière sur eux. C’est un point connu dans l’industrie depuis l’apparition des WLCSP, et tout ingénieur responsable doit l’intégrer comme contrainte de conception. Une puce en silicium est en quelque sorte un petit panneau solaire, donc elle réagit naturellement à la lumière. Les capteurs d’image CMOS sont aussi une technologie issue du fait d’éclairer intensément des puces mémoire, et une puce WLCSP est essentiellement une puce de silicium sans véritable packaging. Tout cela est déjà bien connu. Le décapsulage pour utiliser des transistors comme capteurs optiques ou cellules solaires est aussi une vieille pratique, et les premiers phototransistors utilisaient déjà des boîtiers avec fenêtre au lieu de bloquer la lumière. Si l’on monte directement un WLCSP sur un PCB non protégé alors que la photosensibilité pose problème, j’ai tendance à penser que le concepteur est débutant ou devrait être davantage encadré. Lire les fiches techniques avant d’utiliser une pièce à grande échelle, et comprendre la structure des puces en silicium ainsi que les principes des jonctions semi-conductrices, fait partie des bases du métier d’ingénieur. L’article lui-même était intéressant, mais son ton un peu intrusif et ses résumés incessants m’ont fortement fait sentir l’influence d’un LLM ou de l’IA
  • L’article ne prétendait pas que la photosensibilité des composants WLCSP avait été découverte pour la première fois par la communauté. Il contient une section intitulée « This Wasn’t Actually Unprecedented », qui mentionne des cas antérieurs, leurs causes, et renvoie vers des articles liés. Ce qui était réellement nouveau ici, c’était le problème de photosensibilité du Raspberry Pi 2 ; la photosensibilité des WLCSP elle-même était déjà connue. La plupart des PCB ne sont pas exposés au consommateur, donc le problème se manifeste rarement en pratique. Dire qu’un concepteur ayant utilisé un WLCSP non protégé dans des conditions où cette photosensibilité était inacceptable est forcément débutant me paraît exagéré. Il a fallu ici une source lumineuse extrêmement puissante et spécifique, comme un flash au xénon, combinée à un PCB exposé — un cas très rare — et il est possible que la fiche technique du composant n’en parlait même pas
  • Le même débat avait déjà eu lieu il y a 10 ans. À l’époque, la fiche technique utilisée par le Raspberry Pi indiquait : « la protection du circuit contre la photosensibilité mentionnée dans la littérature connexe ne pose pas de problème en pratique. Le silicium n’est transparent qu’aux longueurs d’onde élevées. Cette lumière est rare dans les principaux environnements d’utilisation du WLCSP » https://web.archive.org/web/20150210111428/https://www.fairchildsemi.com/application-notes/AN/AN-5075.pdf
  • Je suis d’accord sur le fait qu’on ne devrait pas s’attendre à un fonctionnement normal en mettant des puces nues sur une carte non protégée. Il y a déjà eu par le passé des cas où une encapsulation plastique contenait trop peu de noir de carbone, rendant le composant sensible à la lumière, et certains anciens composants étaient même empaquetés dans un plastique brun qui n’était pas opaque. https://electronics.stackexchange.com/questions/217423/ics-chips-are-typically-packaged-in-what-material
  • Je ne pense pas que tous les composants WLCSP présentent réellement une photosensibilité marquée. La plupart des dispositifs CSP ont un revêtement sur le dessus de la puce, donc les problèmes de photosensibilité peuvent se limiter à certains bords ou à la lumière réfléchie. En pratique, seuls certains composants posent problème, et dans ce cas on est proche d’un défaut de conception. Selon le type de composant utilisé, mais pour de la logique générale, des processeurs ou des composants d’alimentation, il n’y a presque jamais de photosensibilité significative ; les problèmes concernent surtout les circuits de band gap ou d’oscillateur sensibles à la lumière. Dans ce type de cas, une modification du layout peut atténuer le problème
  • J’ai appris quelque chose de nouveau aujourd’hui ! J’ai déjà utilisé ce type de boîtier plusieurs fois, mais je le considérais presque comme du BGA. Pour moi, c’était simplement une option quand il fallait quelque chose de plus petit que du QFN, ou quand il n’y avait que ça de disponible, au prix du fait qu’on ne peut pas inspecter visuellement les broches. Hors signaux haute vitesse ou RF, j’avais aussi tendance à ne pas trop me soucier du footprint, et quand une carte comporte beaucoup de composants avec des fiches techniques longues, il est facile de passer à côté de ce genre de détail. Quand on s’habitue à ne lire que les parties jugées importantes, les détails deviennent faciles à manquer, mais ce cas montre bien que pour un appareil produit en volume, une vérification minutieuse est d’autant plus essentielle
• Si l’auteur lit les commentaires HN, j’aimerais lui dire que l’ajout répété d’informations accessoires qui n’expliquent pas vraiment le fond du sujet (par exemple « le phénomène pour lequel Einstein a reçu le Nobel », « Blu-Tack (vraiment) », ou les histoires de confiance communautaire) a fini par être plus agaçant qu’intéressant. J’ai vu sur la page « about » de l’auteur qu’un LLM est utilisé pour l’écriture ; je lui suggérerais donc de moins s’appuyer sur ce type d’outil, ou d’examiner le résultat de manière plus critique. C’est l’un des rares billets de blog que j’ai lus où intérêt et irritation se sont alternés à ce point
  • Au contraire, la référence à Einstein m’a aidé à raviver rapidement ce dont je me souvenais de mes cours de physique. Comme la présentation ressemblait davantage à un récit qu’à un rapport, j’ai trouvé la lecture plus agréable
  • Cela dépend des gens, mais j’ai l’impression qu’avec les textes issus de LLM, la couleur personnelle de chaque auteur disparaît peu à peu, ce qui rend regrettable cette habitude de « juste faire passer le texte une dernière fois dans un LLM ». Tous les textes finissent par reprendre une tonalité similaire, ce qui les rend plus monotones
  • Quand des formules comme « This highlights » ou « This contrasts with » reviennent sans cesse, cela devient vraiment pénible à lire. L’introduction était correcte, mais à partir de la conclusion, j’ai trouvé l’ensemble répétitif et assez plat
  • Moi, j’ai trouvé toutes les parties de l’article intéressantes
  • Je suis d’accord avec l’idée que « l’écriture assistée par IA » risque de vite lasser. En revanche, au lieu de discussions avec un LLM, je me dis qu’il serait peut-être préférable qu’une IA présente les résultats de recherche sous forme de document selon le format souhaité pour chaque sujet (résumé simple, extrait YouTube, podcast, liste de faits, etc.). Tant qu’il est clair que le résultat vient d’une machine ou d’une interface, la sortie d’un LLM en elle-même ne me gêne pas tant que ça
• Cet incident m’a rappelé un autre bug matériel : « l’allergie des iPhone à l’hélium » https://www.ifixit.com/News/11986/iphones-are-allergic-to-he...
  • Ce qui rendait le cas de l’hélium intéressant, c’est qu’à l’époque, même les fabricants de dispositifs MEMS n’avaient pas étudié en profondeur l’effet de différents gaz ambiants. Pour les techniciens terrain, c’était d’autant plus facile à manquer, surtout sans familiarité avec les procédés de fabrication MEMS. Les fabricants utilisent des mélanges gazeux validés lors des réglages initiaux, donc pour eux ce n’était probablement pas un grand choc, mais du point de vue d’un ingénieur généraliste, c’était un angle mort peu visible
  • Il y a aussi une bonne vidéo de suivi sur la sensibilité à l’hélium https://www.youtube.com/watch?v=vvzWaVvB908
• Chaque modèle pair de Pi a eu un défaut matériel intéressant
  • Pi 2 : problème de redémarrage causé par le flash d’un appareil photo
  • Pi 4 : erreur dans le circuit de charge USB-C (pas d’alimentation avec plusieurs adaptateurs PD) https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4... Je possède les modèles d’origine des Pi 1 et Pi 4, et leurs défauts ne posaient problème que dans des conditions particulières. Le Pi 5, à part l’exigence de 5V/5A (même si avec un bon adaptateur, 5V/3A passe généralement bien), n’a pas eu de problème matériel aussi sérieux que les modèles 2 ou 4. Cela donne envie de se demander ce qui arrivera avec le Pi 6
  • Tu te souviens que la sortie du premier Pi avait été retardée à cause d’un problème sur le magnétisme Ethernet ? Il fallait une prise avec magnétics intégrés, mais le mauvais composant avait été utilisé. Ça fait mesurer le chemin parcouru depuis
  • Le Pi 3 avait des problèmes de tension, résolus avec un adaptateur spécial 5.1V. Tous les modèles ont eu des soucis de durabilité des microSD, et le PoE HAT a aussi connu des problèmes. Le point commun à tous les Raspberry Pi, c’est que leur circuit d’alimentation embarqué est excessivement simple, voire quasi inexistant. Je me souviens aussi avoir lu quelque part une rumeur disant que, du fait de la réglementation britannique/européenne, une carte nue ne peut pas toujours être vendue comme produit grand public dans certains cas
  • Le Pi 1 avait aussi des défauts matériels. Par exemple, le problème du régulateur 1.8V du LAN9512, ou les brownouts sur les ports USB
  • Je me demande si la série Compute Module a connu les mêmes problèmes
  • Je trouve dommage d’exagérer avec des formulations du type « tous ». Cela m’a un peu déçu venant de quelqu’un que je respectais habituellement
• Je trouve fascinant que les propriétés des matériaux semi-conducteurs puissent souvent être inversées. Une LED est un panneau solaire inefficace, et l’inverse est également vrai. Ce qui est intéressant ici, c’est que si l’on excite une jonction avec une source IR de forte intensité, la jonction excitée peut à son tour émettre un rayonnement IR, que l’on peut capter avec une caméra si le boîtier est suffisamment fin. En théorie, on pourrait donc suivre visuellement l’activation de certaines jonctions. En pratique, toutefois, ce n’est pas très efficace, le signal est faible, et il peut falloir appliquer un survoltage important ou underclocker fortement la puce. Je ne suis pas sûr que cela devienne réellement testable dans de bonnes conditions. J’ai oublié le nom de l’entreprise qui voulait commercialiser ce type de technique
  • Un autre exemple amusant : si l’on fait tourner un moteur DC à la main, il produit du courant. C’est évident quand on pense au fait que moteur et générateur reposent sur le même principe, mais si l’on part d’abord du moteur, cela ressemble à un paradoxe assez contre-intuitif
• Cela m’a rappelé un cas où le cache d’un CPU SPARC avait été corrompu à cause de la désintégration radioactive d’impuretés présentes dans le boîtier de la puce. Je me souviens avoir passé pas mal de temps sur ce problème à mon premier emploi
  • Il y a une excellente anecdote sur des puces mémoire IBM. Je l’ai recopiée dans un commentaire lié, voir ici https://news.ycombinator.com/item?id=25279964
• Je me souviens avoir rencontré le même problème à cause d’un cache en plastique transparent pour appareil auditif. À certains angles, une exposition au soleil ou au flash produisait du bruit, mais personne ne me croyait
• Lors d’une « Tiger Cruise », j’utilisais une DV Cam sur un porte-avions, et la vidéo se brouillait toutes les 3 secondes sur le pont. Cela correspondait exactement à la période de balayage du radar. J’ai tout de suite compris qu’il s’agissait de rayonnement, puis j’ai orienté l’appareil de sorte qu’une batterie de téléphone portable (contenant des métaux lourds) se trouve entre le radar et la tête magnétique ; le problème de coupure vidéo a alors totalement disparu
• Voici le lien vers la discussion HN de l’époque https://news.ycombinator.com/item?id=9015663
• Le débogage post-mortem des semi-conducteurs flip-chip peut aussi se faire en envoyant un laser sur un point précis puis en détectant la lumière réfléchie pour déterminer si un transistor est à l’état on ou off. En augmentant la puissance du laser, on peut même forcer directement certains transistors à s’ouvrir ou se fermer. Les semi-conducteurs sont naturellement sensibles à la lumière, et c’est justement pour les protéger qu’on encapsule les puces dans des boîtiers opaques