Le flash mortel au xénon : l’incident où un appareil photo a failli mettre hors service le Raspberry Pi 2
(magnus919.com)- En février 2015, Peter Onion a constaté qu’en photographiant son nouveau Raspberry Pi 2, la carte s’éteignait immédiatement à chaque déclenchement du flash ; des expérimentations collectives sur le forum ont permis de cerner la cause
- Il ne s’agissait pas d’un simple problème d’appareil photo : le phénomène ne se reproduisait qu’avec une lumière intense comme un flash au xénon ou un pointeur laser, et disparaissait lorsque l’on masquait certains composants ou que l’on retournait la carte
- Le point vulnérable était le régulateur d’alimentation U16, situé entre le connecteur USB et le port HDMI ; le silicium exposé par le packaging WL-CSP provoquait un effet photoélectrique qui perturbait le circuit de régulation de tension
- La solution provisoire consistait à couvrir U16 avec un matériau opaque comme de la Blu-Tack, du ruban isolant ou du mastic ; le problème a été corrigé fin 2015 avec la révision matérielle 1.2 du Pi 2, grâce à une modification de l’architecture de gestion de l’alimentation
- Ce cas a montré que le packaging à l’échelle de la puce, avantageux pour la miniaturisation et la réduction des coûts, peut créer des modes de défaillance par interférences optiques faciles à manquer lors des validations classiques
Un Raspberry Pi 2 éteint par un simple flash
- En février 2015, Peter Onion photographiait son nouveau Raspberry Pi 2 lorsqu’il a constaté que le Pi s’éteignait immédiatement à chaque déclenchement du flash de l’appareil photo
- Il a d’abord pensé à une coïncidence, mais après trois occurrences consécutives, il a publié un message sur le forum Raspberry Pi intitulé « Why is the PI2 camera-shy? »
- Peter Onion était un membre de longue date de la communauté Raspberry Pi et participait régulièrement aux Raspberry Jam de Cambridge et de Bletchley ; la communauté s’est donc rapidement mise à expérimenter
Ce n’était pas une LED, mais le flash au xénon qui donnait l’indice
- Les utilisateurs du forum ont testé différents appareils photo et sources lumineuses afin de réduire les conditions de reproduction
- L’utilisateur « jdb » a découvert qu’il n’y avait aucun problème avec le flash LED du Samsung Note2, mais que le flash au xénon du Samsung K Zoom éteignait systématiquement le Pi 2
- Cette différence a permis d’écarter l’usage de l’appareil photo en lui-même et de concentrer l’enquête sur une lumière présentant une intensité et des caractéristiques particulières
Le composant en cause était le régulateur d’alimentation U16
- Au départ, la puce principale du processeur a été suspectée, mais recouvrir le processeur avec de la Blu-Tack ne résolvait pas le problème
- Lorsque le Pi était retourné, il n’était plus affecté par le flash, confirmant que la lumière devait toucher directement un composant précis de la carte pour déclencher le problème
- Après des tests méthodiques, le petit régulateur d’alimentation U16, situé entre le connecteur USB et le port HDMI, a été identifié comme le point vulnérable
- Quand seul U16 était masqué avec de la Blu-Tack, les plantages cessaient complètement, ce qui a permis de conclure que le problème ne venait pas d’un contact électrique, mais d’une exposition optique
Le WL-CSP et l’effet photoélectrique ont créé les conditions d’arrêt
- La puce U16 utilisait un Wafer-Level Chip Scale Packaging (WL-CSP)
- Dans ce type de packaging, les billes de soudure sont fixées directement sur le die de silicium, qui est ensuite monté sur le circuit imprimé
- Contrairement aux packagings traditionnels enveloppés dans du plastique opaque, le WL-CSP privilégie la miniaturisation au prix d’une protection réduite
- Lorsqu’une lumière de forte intensité atteint le silicium exposé, un effet photoélectrique se produit
- Des photons de haute énergie génèrent dans le semi-conducteur des flux d’électrons inattendus, perturbant le circuit de régulation de tension et provoquant un arrêt immédiat
- Le seuil d’intensité était la condition essentielle
- Les flashes LED ordinaires d’appareils photo ne produisaient pas assez de photons
- Les flashes au xénon et les pointeurs laser étaient assez puissants pour provoquer le dysfonctionnement
- L’infrarouge et la lumière visible pouvaient aussi poser problème à très forte intensité, mais l’énergie de bande interdite propre au silicium entrait en jeu comme condition déterminante
Des cas d’interférences optiques existaient déjà
- L’incident du Raspberry Pi 2 a beaucoup attiré l’attention, mais des problèmes similaires d’interférences optiques existaient déjà dans l’industrie des semi-conducteurs
- Un ingénieur d’EDN Network avait rencontré le même problème 12 ans plus tôt avec un amplificateur CSP destiné à un prototype de téléphone portable
- Lorsque la lumière du flash de l’appareil photo intégré au téléphone traversait le packaging de la puce, la sortie de l’amplificateur présentait des pics
- Un incident similaire s’était aussi produit en 1997 à la centrale nucléaire de Haddam Neck, dans le Connecticut
- Un membre du service de formation avait photographié au flash un panneau de détection incendie
- Le flash de l’appareil photo avait trompé une puce EPROM en lui faisant croire qu’un incendie s’était déclaré, et le système d’extinction au Halon s’était déclenché en quelques secondes
- Les opérateurs avaient dû quitter la salle de contrôle pendant 35 minutes, le temps que le gaz se dissipe
- Ces exemples montrent que, lorsque les semi-conducteurs deviennent plus petits et plus exposés, ils peuvent devenir vulnérables à des interférences optiques que les tests traditionnels ne prennent pas en compte
Blindage provisoire et révision matérielle
- La solution immédiate consistait à couvrir la puce U16 avec un matériau ne laissant pas passer la lumière
- La Raspberry Pi Foundation recommandait des matériaux opaques comme la Blu-Tack, le ruban isolant ou le mastic
- L’idée était d’empêcher la lumière d’atteindre le semi-conducteur sensible tout en conservant un fonctionnement électrique normal
- La correction de fond est arrivée avec la révision matérielle 1.2 du Pi 2, lancée fin 2015
- Il ne s’agissait pas d’un simple blindage : une autre architecture de gestion de l’alimentation a été introduite, utilisant le système sur puce BCM2837 également employé dans le Pi 3
- Une meilleure conception du circuit a supprimé la sensibilité optique
- Les tests ont montré que les modèles Raspberry Pi antérieurs — A, B, A+ et B+ — n’étaient pas vulnérables au « xenon death flash » ; ce problème était propre à la génération 2
Un mode de défaillance facile à manquer dans l’électronique moderne
- La pression de conception en faveur de composants plus petits et moins coûteux peut créer des modes de défaillance que les tests traditionnels ne prennent pas en compte
- Les tests standard de compatibilité électromagnétique couvrent les interférences radio, mais il n’est généralement pas prévu de vérifier si prendre un ordinateur en photo peut l’éteindre
- Le packaging à l’échelle de la puce, comme le WL-CSP, rend possibles des appareils petits et puissants, mais revient en pratique à placer un die de silicium sur un circuit imprimé avec une protection minimale
- Les avantages en coût et en taille peuvent s’accompagner d’une moindre robustesse environnementale
- La combinaison d’un appareil photo à flash au xénon orienté vers une puce de régulation d’alimentation exposée se situait en dehors des scénarios de validation habituels
La valeur pédagogique d’un « bug adorable »
- La Raspberry Pi Foundation a traité l’incident avec transparence, l’a qualifié de « bug le plus adorable que nous ayons vu » et l’a transformé en leçon de physique sur l’effet photoélectrique
- Cette vulnérabilité est devenue un cas d’école en électronique pour montrer comment les principes de la physique agissent dans des technologies réelles
- Les élèves pouvaient observer directement l’effet photoélectrique en voyant un ordinateur s’éteindre lorsqu’on le photographiait
- L’incident est resté comme un exemple ayant rendu la conception des semi-conducteurs plus attentive aux interférences optiques
- La réaction du forum Raspberry Pi a montré que, lorsqu’un bug étrange apparaît, les expériences et la collaboration de nombreux utilisateurs peuvent être efficaces pour en identifier la cause
1 commentaires
Avis de Hacker News
La photosensibilité des composants WLCSP n’a pas été « découverte » par la communauté
Les fiches techniques des composants WLCSP mentionnent généralement la photosensibilité, et fournissent aussi des données sur la façon dont la lumière peut affecter le composant
C’est quelque chose de connu depuis les débuts du WLCSP, et tout ingénieur responsable le traite comme un paramètre de conception
Une puce en silicium est, en pratique, constituée d’une multitude de petites jonctions de cellule solaire, donc sensible à la lumière, et une puce WLCSP est quasiment une puce en silicium sans véritable boîtier
Retirer le capuchon d’un transistor pour l’utiliser comme photodétecteur ou cellule solaire se faisait déjà depuis longtemps, et les premiers phototransistors étaient aussi de simples composants NPN standard dans un boîtier métallique doté d’une fenêtre
Si l’on place un composant WLCSP sur un PCB non protégé alors que la conception ne tolère pas la photosensibilité, c’est une erreur de débutant, qui nécessite la supervision d’un ingénieur senior
Avant d’intégrer un composant dans des millions d’appareils, lire la fiche technique et comprendre le fonctionnement des jonctions semi-conductrices relève de la responsabilité de base
Cela dit, l’article lui-même est intéressant, mais son rythme verbeux et ses résumés répétés donnent l’impression qu’une sortie de LLM a été utilisée, ou fortement mêlée au texte
Ce qui a été découvert, ce n’est pas que les composants WLCSP sont sensibles à la lumière, mais que le Raspberry Pi 2 était sensible à la lumière
La plupart des PCB ne sont pas distribués aux consommateurs sous forme de cartes nues exposées, donc ce type de problème apparaît rarement côté utilisateur final
La photosensibilité des WLCSP est un phénomène rare, qui nécessite la combinaison d’un PCB exposé et d’une source lumineuse très intense et spécifique — ici, un flash au xénon —, il n’y a donc pas lieu d’en faire toute une histoire
Dès qu’il est question de Raspberry Pi, certains semblent vouloir traiter les ingénieurs de « bricoleurs » ou de « débutants », mais c’est vraiment un cas limite rare
Je ne serais même pas surpris que la fiche technique du composant en question ne mentionne pas du tout la photosensibilité
« La protection des circuits photosensibles évoquée dans la littérature n’est pas une préoccupation réaliste. Le silicium n’est transparent qu’à la lumière de grande longueur d’onde, qui est rarement rencontrée dans les nombreuses applications des WLCSP »
https://web.archive.org/web/20150210111428/https://www.fairc...
Il y a aussi eu par le passé des cas où l’encapsulation plastique ne contenait pas assez de noir de carbone, rendant des composants photosensibles, et certains vieux composants avaient des boîtiers en plastique brun pas assez opaques
C’est un problème qui existe depuis des décennies
[1] https://electronics.stackexchange.com/questions/217423/ics-c...
La plupart des composants CSP ont un revêtement arrière qui protège le dessus de la puce de la majeure partie de la lumière, si bien que la photosensibilité subsiste surtout sur les bords du composant ou via des réflexions par-dessous
Certains posent problème, mais j’y vois plutôt un défaut de conception qu’un problème intrinsèque à tous les composants WLCSP
Cela dépend aussi du type de composant que l’on fabrique. La logique numérique de base, les processeurs et les composants de puissance ne devraient pas subir de problèmes significatifs à cause de la lumière
En général, le problème vient de la photosensibilité des circuits bandgap ou des oscillateurs, et il peut être atténué en modifiant l’implantation sur la puce
Autrement dit, on le choisit quand le composant n’existe que dans ce boîtier, ou quand on veut quelque chose de plus petit qu’un QFN, et qu’on accepte de ne pas pouvoir inspecter visuellement les broches
Si l’on ne traite pas de signaux haut débit ou de RF, on peut généralement s’en sortir avec les abstractions habituelles de schéma et d’empreinte
Je comprends aussi pourquoi ce genre de problème peut passer inaperçu. Une carte comporte beaucoup de composants, les fiches techniques sont longues, et on prend l’habitude de lire en priorité les parties importantes comme la description du protocole, le pinout, le placement de référence ou les tolérances de tension
Lire les petits caractères aurait pu éviter le problème, mais les sauter peut se justifier dans une certaine mesure. Pour un appareil produit à une telle échelle, cela se justifie sans doute moins
Si l’auteur lit HN, j’aimerais lui dire que son style d’écriture m’a pas mal agacé
Le texte contient des informations étranges qui n’aident pas vraiment l’explication, par exemple des formules comme « le même phénomène qu’Einstein a expliqué et qui lui a valu le prix Nobel », ainsi que beaucoup de procédés qui dramatisent les choses plus qu’elles ne le sont vraiment, comme « Blu-Tack (vraiment) » ou le récit autour de la confiance de la communauté
La page de présentation indique qu’il utilise un LLM comme aide à l’écriture ; j’aimerais qu’il s’y appuie moins, ou au moins qu’il examine ses sorties de façon plus critique
Je n’avais jamais été aussi frustré en lisant un billet de blog, en oscillant entre intérêt et agacement
Je l’ai davantage lu comme une histoire que comme un rapport, et je l’ai d’autant plus apprécié
Tous les textes finissent par se ressembler de plus en plus et par devenir monotones
Le début était correct, mais arrivé à la conclusion, c’était terriblement monotone
En revanche, au lieu de discuter avec un LLM, on peut imaginer une IA qui présente les résultats de recherche sur un sujet donné dans le format souhaité
Par exemple sous forme de petit article léger, de clip façon TikTok, de vidéo YouTube, de podcast, ou de format « seulement les faits »
Si le fait que ce soit produit par une machine ou une UI est évident, les sorties de LLM ne me dérangent pas tant que ça
Un autre défaut matériel classique est le cas où les iPhone sont sensibles à l’hélium
[1] https://www.ifixit.com/News/11986/iphones-are-allergic-to-he...
Même un ingénieur consciencieux aurait pu passer à côté s’il ne connaissait pas bien les procédés de fabrication MEMS, et ce procédé n’était pas largement connu avant d’être rendu public
Cela dit, du point de vue du fabricant de composants, cela n’avait probablement rien de surprenant. L’utilisation de mélanges gazeux calibrés pour le réglage initial fait partie des étapes de conception standard
https://www.youtube.com/watch?v=vvzWaVvB908
Chaque modèle Raspberry Pi à numéro pair a eu des quirks intéressants qu’il a fallu « corriger » par une modification matérielle
Le Pi 2 avait le problème de redémarrage provoqué par le flash d’un appareil photo, et le Pi 4 avait un problème où beaucoup d’adaptateurs PD ne fournissaient pas d’alimentation à cause d’une erreur dans l’implémentation du circuit de charge USB-C
Je possède et utilise encore les modèles originaux des deux, mais ces défauts matériels ne posaient problème que dans certaines situations
Le Pi 5 a une exigence particulière de 5 V / 5 A, mais si l’on n’utilise pas d’accessoires USB à forte puissance et que l’on dispose d’un bon adaptateur secteur, il fonctionne très bien aussi en 5 V / 3 A
En revanche, il n’y a pas encore eu de bizarrerie matérielle du niveau des Pi 2/4
La question est donc la suivante : qu’est-ce que ce sera pour le Pi 6 ?
[1] https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4...
Tous les modèles ont aussi eu des problèmes de durée de vie des microSD, et le PoE HAT a lui aussi eu des soucis
Le point commun de tous les modèles de Pi est que le circuit d’alimentation embarqué est assez simple, voire absent
J’ai l’impression d’avoir lu quelque part que cela pouvait être lié à la réglementation de l’UE/du Royaume-Uni. L’idée était que, sinon, il serait interdit de vendre une carte nue comme produit grand public ; je me demande si quelqu’un a lu ou entendu quelque chose de similaire
Dans mon souvenir, il fallait un jack avec magnétiques intégrés, mais le mauvais composant avait été monté
On a vraiment parcouru du chemin depuis
Fait amusant : les effets des semi-conducteurs sont souvent réversibles
Une diode électroluminescente est un panneau solaire inefficace, et l’inverse est également vrai
La raison pour laquelle c’est pertinent ici est que le même effet qui permet de stimuler une jonction avec de l’infrarouge de forte intensité fonctionne aussi dans l’autre sens
Une jonction stimulée émet de l’infrarouge et, si le boîtier est assez fin, on peut le détecter
Avec la bonne caméra, on pourrait en théorie filmer l’activation de jonctions spécifiques dans une puce
En pratique, toutefois, c’est difficile à cause du rendement ; je ne sais pas combien de photons une jonction émet par cycle d’horloge, mais ce ne doit pas être beaucoup
Ces photons doivent ensuite sortir du boîtier et être captés par le capteur ; pour obtenir un signal utile, il faudrait donc probablement faire fonctionner la puce avec une surtension assez importante ou réduire l’horloge
Je ne sais donc pas à quel point ce test serait « fonctionnel ». J’aimerais me souvenir du nom de l’entreprise qui essayait de commercialiser ça
Cela paraît logique si l’on part de l’idée d’un générateur, mais quand on a d’abord utilisé un moteur DC « dans l’autre sens », c’était assez contre-intuitif
Cela me rappelle un problème de corruption du cache d’un CPU SPARC qui m’a fait perdre beaucoup de temps dans mon premier emploi
Il était dû à des impuretés dans le packaging de la puce qui subissaient une désintégration radioactive
Nous avions eu le même problème avec de jolis couvercles translucides sur des appareils auditifs
Quand la lumière du soleil arrivait sous un certain angle, ou lorsqu’un flash se déclenchait, cela produisait du bruit, mais personne ne voulait le croire
Cela me rappelle un problème étrange que j’ai rencontré avec une DV Cam emportée lors d’une « tiger cruise »
Une tiger cruise est un événement où, au retour de mission d’un porte-avions, les familles sont invitées à monter à bord ; nous avons fait le trajet de Honolulu à San Diego
Sur le pont, la vidéo se dégradait toutes les 3 secondes, et j’ai vite compris que cela coïncidait exactement avec la rotation du réseau radar
En supposant que c’était dû à un type de rayonnement, j’en ai déduit que si je tenais mon téléphone incliné de manière à placer la batterie, c’est-à-dire la partie contenant des métaux lourds, entre le réseau radar et la tête magnétique, la vidéo ne se couperait plus toutes les 3 secondes
Ça a vraiment très bien marché
Fil HN de l’époque : https://news.ycombinator.com/item?id=9015663
Le point clé était le seuil d’intensité
Les flashs LED ordinaires d’appareil photo ne produisaient pas assez de photons, mais les flashs au xénon et les pointeurs laser étaient suffisamment intenses pour provoquer un dysfonctionnement
Ce qui est encore plus intéressant, c’est que cet effet nécessitait une énergie de bande interdite spécifique du silicium
Autrement dit, l’infrarouge et la lumière visible peuvent potentiellement poser problème, mais seulement à des intensités extrêmes
L’article semble confondre intensité et longueur d’onde. À moins qu’il ne soit question d’absorption multiphotonique non linéaire, ce qui n’est atteignable qu’avec de puissantes impulsions laser ultrarapides