Xenon Death Flash: el incidente en que una cámara casi arruina la Raspberry Pi 2

• Se detectó un comportamiento anómalo en el que la Raspberry Pi 2 se apagaba cada vez que quedaba expuesta al flash de xenón de una cámara
• La causa de este fenómeno fue el efecto fotoeléctrico que se producía al entrar luz en el chip regulador de energía (U16), que usaba encapsulado WL-CSP
• Los experimentos de la comunidad revelaron que el flash LED no causaba problemas, pero el flash de xenón o un puntero láser sí provocaban fallas
• La solución inmediata fue cubrir el chip U16 con un material opaco, aunque después una revisión de hardware mejoró el diseño del circuito de raíz
• Este incidente es un caso emblemático de la vulnerabilidad a la interferencia óptica en dispositivos electrónicos ultracompactos y de la importancia de la colaboración comunitaria

---

Introducción: el extraño bug provocado por el flash de una cámara

• En febrero de 2015, Peter Onion, veterano de la comunidad Raspberry Pi, experimentó un problema mientras fotografiaba una nueva Raspberry Pi 2: cada vez que se disparaba el flash de la cámara, la Pi se apagaba de inmediato
• Al ver que se repetía, concluyó que no era una coincidencia y compartió lo ocurrido en el foro de Raspberry Pi
• La comunidad empezó de inmediato a hacer pruebas con varias cámaras y fuentes de luz, y descubrió que el flash LED no causaba problemas, pero el apagado solo ocurría con flash de xenón

The Hunt for the Vulnerable Component

• La investigación de la causa se centró en identificar qué componente de la Raspberry Pi 2 era vulnerable
• Se probaron métodos como cubrir el chip del procesador principal con Blu-Tack (una especie de masilla adhesiva)
• Cuando algunos miembros de la comunidad hicieron pruebas con el dispositivo al revés, se confirmó que era un problema relacionado con la luz, ya que no reaccionaba al flash
• Experimentos adicionales identificaron al chip U16 entre el conector USB y el HDMI como la causa principal; con solo taparlo, el problema desaparecía por completo

La física detrás del “Xenon Death Flash”

• El chip U16 usaba una estructura Wafer-Level Chip Scale Packaging (WL-CSP), en la que el dado de silicio quedaba expuesto directamente sobre la placa sin una cápsula protectora
• Al exponerse a una fuente de luz externa de alta intensidad, se producía un efecto fotoeléctrico, donde fotones de alta energía generaban un flujo inesperado de electrones dentro del chip
• Esto afectaba el circuito regulador de voltaje y terminaba provocando el apagado inmediato de la Pi 2
• El flash LED era inocuo por falta de fotones suficientes, pero el flash de xenón o un puntero láser sí tenían la energía necesaria para activar esta vulnerabilidad

Problemas de interferencia óptica que ya existían

• Antes de la Raspberry Pi 2 ya se habían encontrado casos de vulnerabilidades similares por interferencia óptica
• Un ejemplo representativo fue el de un chip amplificador CSP en un prototipo de teléfono móvil, hace 12 años, que fallaba por el flash de una cámara
• En 1997, en la planta nuclear Haddam Neck de Estados Unidos, tomar fotos con flash alteró un chip EPROM del panel contra incendios, al punto de activar incluso el sistema de liberación de gas
• Esto demuestra que, a medida que los componentes electrónicos se vuelven más pequeños y expuestos, aumenta su vulnerabilidad al entorno lumínico

Soluciones: de Blu-Tack a mejoras de diseño

• Como respuesta inmediata, se recomendó cubrir el chip U16 con un material opaco (Blu-Tack, cinta aislante, masilla)
• Al bloquear físicamente la luz, la vulnerabilidad se resolvía de forma temporal
• Más adelante, en la segunda mitad de 2015, la Raspberry Pi 2 Rev 1.2 cambió la estructura de administración de energía y el chip por una base BCM2837, eliminando de raíz esta vulnerabilidad óptica
• Los modelos Pi de generaciones anteriores no se veían afectados por este problema debido a su estructura

Lo que esto sugiere sobre las vulnerabilidades de los dispositivos electrónicos modernos

• La vulnerabilidad de la Pi 2 muestra que la búsqueda de ultraminiaturización y bajo costo puede crear nuevas debilidades inesperadas
• Las pruebas tradicionales en electrónica suelen considerar solo la interferencia electromagnética, mientras que la revisión ante interferencia óptica sigue siendo insuficiente
• Tecnologías como WL-CSP aportan reducción de tamaño y costos, pero tienen puntos débiles en términos de protección
• También sugiere que entornos de uso anómalos que no se habían previsto, como fotografiar con flash, pueden detonar problemas nuevos

El legado de un “bug encantador”

• La Raspberry Pi Foundation describió este bug como “el bug más adorable de todos los tiempos” y divulgó el problema con transparencia
• Este incidente se consolidó como un caso educativo de ingeniería electrónica que permite experimentar el efecto fotoeléctrico en la vida real
• Además, ayudó a aumentar la conciencia sobre los problemas de interferencia óptica en el diseño de semiconductores
• Aunque muy específico, también dejó claro para toda la industria que hace falta diversificar los procesos de validación

Lecciones para hoy

• Esta historia sirve como advertencia sobre la seguridad del hardware y los efectos secundarios de una miniaturización agresiva
• Los dispositivos embebidos de la era del IoT podrían albergar vulnerabilidades potenciales similares a la de la Pi 2
• Los bugs más interesantes suelen aparecer en la intersección entre tecnologías no relacionadas
• Demuestra la importancia del poder de la resolución colectiva de problemas en comunidades como la de Raspberry Pi
• Es un caso representativo de cómo la curiosidad y la colaboración pueden resolver hasta los problemas más extraños

[GN⁺]

Comentarios en Hacker News

• Quiero señalar que la fotosensibilidad de los componentes WLCSP no fue algo que la comunidad “descubrió”. Las hojas de datos de WLCSP ya indican que esos componentes tienen fotosensibilidad e incluyen datos sobre el efecto de la luz en ellos. Esto se conoce en la industria desde que apareció WLCSP, y cualquier ingeniero responsable debería considerarlo como un factor de diseño. Los chips de silicio son básicamente pequeños paneles solares, así que naturalmente responden a la luz. Los sensores de imagen CMOS también son una tecnología creada al iluminar intensamente chips de memoria, y los chips WLCSP son, en la práctica, chips de silicio sin un encapsulado real. Todo esto ya se sabía. Usarlos como fotosensores o celdas solares mediante decap para abrir el encapsulado del transistor también es algo antiguo, y los primeros fototransistores usaban cápsulas con ventana precisamente para no bloquear la luz. Si montas WLCSP directamente en un PCB sin protección y la fotosensibilidad es un problema, creo que el diseñador es principiante o necesita más supervisión. Leer la hoja de datos antes de usar una pieza a gran escala, y entender la estructura de los chips de silicio y los principios de las uniones semiconductoras, es parte de las capacidades básicas de ingeniería. El artículo en sí fue interesante, pero el tono metiche y la forma de resumir todo constantemente me hicieron sentir con mucha fuerza la influencia de un LLM o de la IA
  • El artículo no afirmaba que la fotosensibilidad de los componentes WLCSP hubiera sido descubierta por primera vez por la comunidad. Hay una sección titulada “This Wasn’t Actually Unprecedented”, donde menciona casos anteriores y la causa, y además enlaza artículos relacionados. Lo realmente nuevo aquí fue el problema de fotosensibilidad del Raspberry Pi 2; la fotosensibilidad de los componentes WLCSP en sí ya era conocida. La mayoría de los PCB no quedan expuestos al consumidor, así que simplemente no era un problema que saliera a la vista con frecuencia. Me parece exagerado decir que, si se usó un componente WLCSP sin protección en condiciones donde la fotosensibilidad era inaceptable, entonces el diseñador debía ser novato. Es un caso muy raro donde coinciden una fuente de luz extremadamente potente y específica como un flash de xenón con un PCB expuesto, y hasta pienso que quizá eso ni siquiera estaba mencionado en la hoja de datos del componente
  • Esa misma discusión ya había ocurrido hace 10 años. La hoja de datos que usaba Raspberry Pi en ese entonces decía: “la protección de circuitos contra fotosensibilidad mencionada en la literatura relacionada no representa un problema real. Esto se debe a que el silicio solo es transparente a la luz de longitud de onda larga. Ese tipo de luz es poco común en los principales entornos de uso de WLCSP” https://web.archive.org/web/20150210111428/https://www.fairchildsemi.com/application-notes/AN/AN-5075.pdf
  • Coincido en que poner un chip desnudo en una placa sin protección y esperar funcionamiento normal ya era problemático. Antes también hubo casos de sensibilidad a la luz por insuficiente contenido de negro de carbón en el encapsulado plástico, y algunos componentes antiguos venían encapsulados en carcasas plásticas marrones que no eran opacas. https://electronics.stackexchange.com/questions/217423/ics-chips-are-typically-packaged-in-what-material
  • No creo que todos los componentes WLCSP tengan necesariamente una fotosensibilidad claramente perceptible. La mayoría de los dispositivos CSP tienen un recubrimiento sobre la parte superior del chip, así que los problemas de fotosensibilidad podrían limitarse a ciertos bordes o a luz reflejada. Solo algunos componentes realmente causan problemas, y en este caso lo veo más como una falla de diseño. Depende del tipo de dispositivo que uses, pero en lógica general, procesadores o componentes de potencia casi no hay fotosensibilidad relevante; el problema suele aparecer sobre todo en circuitos band gap u osciladores que sí son sensibles a la luz. En esos casos puede mitigarse con cambios de layout
  • ¡Hoy aprendí algo nuevo! He usado este tipo de encapsulado varias veces, pero casi siempre lo veía como si fuera prácticamente igual a un BGA. Lo tomaba como una opción que eliges cuando necesitas algo más pequeño que un QFN o cuando es lo único disponible, aceptando la molestia de no poder inspeccionar visualmente los pines. También tendía a pensar que, salvo señales de alta velocidad o RF, ni siquiera había que preocuparse mucho por el footprint. Cuando la placa lleva muchos componentes y la hoja de datos es larga, es muy fácil pasar por alto cosas así. Si te acostumbras a revisar solo las partes “importantes”, es fácil saltarte detalles, pero este caso deja la lección de que en dispositivos que se van a producir en masa, esa revisión minuciosa importa mucho más
• Si el autor llega a leer el hilo de HN, me gustaría decirle que el texto metía demasiada información de relleno que no era una explicación esencial (por ejemplo: “el fenómeno por el que Einstein ganó el Nobel”, “Blu-Tack (de verdad)”, “la historia de la confianza en la comunidad”, etc.), y eso terminó siendo irritante en vez de interesante. Vi en la página “about” del autor que usa LLM para escribir, y le sugeriría depender menos de esas herramientas de apoyo o revisar el resultado de forma más crítica. Pocas veces un blog me ha provocado alternar tanto entre interés y fastidio como este
  • A mí, en cambio, la referencia a Einstein me ayudó a recordar rápido cosas que había visto en clase de física. Como estaba contado más como historia que como reporte, me resultó más entretenido leerlo
  • Supongo que depende de cada quien, pero siento que con los resultados de los LLM se está perdiendo poco a poco el estilo propio de cada persona, así que me decepciona esa tendencia de “solo pásalo por un LLM al final”. Todo termina sonando parecido y eso lo vuelve aburrido
  • Cuando se repiten expresiones como “This highlights” o “This contrasts with”, de verdad se vuelve pesado de leer. La introducción estaba bien, pero desde la conclusión me pareció repetitivo y monótono
  • A mí me gustó todo el artículo
  • Coincido en que la “escritura asistida por IA” se va a volver cansada muy pronto. Por otro lado, también creo que en lugar de chat con LLM, podría ser mejor que la IA mostrara los resultados de búsqueda como documentos según el formato que uno quiera por tema (resumen breve, clip de YouTube, pódcast, lista de hechos, etc.). Si quedara claro que el resultado viene de una máquina o de una interfaz, la salida de un LLM no me molestaría tanto
• Como otro caso de bug de hardware, me acordé del incidente de la “alergia al helio del iPhone” https://www.ifixit.com/News/11986/iphones-are-allergic-to-he...
  • Lo interesante del caso del helio es que en ese momento ni siquiera los fabricantes de dispositivos MEMS habían investigado a fondo el efecto de distintos gases ambientales. A diferencia de los fabricantes, para los técnicos de campo era algo fácil de pasar por alto, y todavía más si no estaban familiarizados con el proceso de fabricación de MEMS. Los fabricantes usan mezclas de gases validadas durante el ajuste inicial, así que para ellos en realidad no habría sido una gran sorpresa, pero para un ingeniero común era un detalle poco visible
  • También hay un buen video de seguimiento sobre la sensibilidad al helio https://www.youtube.com/watch?v=vvzWaVvB908
• Todos los modelos pares de Pi han tenido alguna falla de hardware interesante
  • Pi 2: reinicios causados por el flash de una cámara
  • Pi 4: error en el circuito de carga USB-C (varios adaptadores PD no suministraban energía) https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4... Tengo los modelos originales de Pi 1 y Pi 4, y sus defectos solo eran un problema en entornos específicos. Fuera de que el Pi 5 requiere 5V/5A (aunque con un buen adaptador normalmente también va bien con 5V/3A), no tiene problemas de hardware tan graves como los modelos 2 o 4. Eso me hace preguntarme qué pasará con el Pi 6
  • ¿Te acuerdas de que el primer Pi tuvo retraso de lanzamiento por un problema con el magnetics de Ethernet? Necesitaban un jack con magnetics integrados, pero usaron la pieza equivocada. Hace pensar cuánto han avanzado desde entonces
  • El Pi 3 tenía problemas de voltaje, y se resolvían con un adaptador especial de 5.1V. Todos los modelos tuvieron problemas de durabilidad con microSD, y también hubo problemas con el PoE HAT. Lo común a todos los Raspberry Pi es que el circuito de alimentación integrado en la placa es excesivamente simple, o directamente inexistente. También recuerdo haber visto por ahí el rumor de que, por regulaciones del Reino Unido/UE, en algunos casos una bareboard no puede venderse como producto de consumo
  • El Pi 1 también tuvo fallas de hardware. Por ejemplo, problemas con el regulador de 1.8V del LAN9512 y brownout en los puertos USB
  • Me pregunto si la serie Compute Module también tuvo problemas de este tipo
  • Me decepcionó un poco esa exageración de decir “todos”; me pesó más viniendo de alguien a quien normalmente respeto mucho
• Me parece fascinante que las propiedades de los materiales semiconductores a menudo puedan invertirse. Un LED es un panel solar ineficiente, y al revés también puede pasar. Lo importante aquí es que, si estimulas una unión con una fuente IR de alta intensidad, la unión estimulada emitirá a su vez radiación IR, y si el encapsulado es lo bastante delgado, eso podría captarse con una cámara. En teoría, sería posible seguir por imagen la activación de ciertas uniones. Pero en la práctica no es eficiente, la señal es débil, y quizá haga falta bastante overvolting o underclocking del chip. No estoy seguro de si llegaría a un nivel realmente comprobable en pruebas. No recuerdo el nombre de la empresa que quería comercializar esta técnica
  • Otro ejemplo curioso es que, si haces girar un motor DC con la mano, genera corriente. Es obvio cuando piensas que el principio del generador y el del motor es el mismo, pero si uno empieza pensando primero en el motor, se siente como una paradoja difícil de asimilar al principio
• Me acordé del caso en que la caché de una CPU SPARC se corrompía por la desintegración radiactiva de impurezas dentro del encapsulado del chip. Recuerdo haber sufrido bastante tiempo con ese problema en mi primer trabajo
  • Hay una gran anécdota sobre chips de memoria de IBM. La dejé en un comentario relacionado, por si te interesa https://news.ycombinator.com/item?id=25279964
• Recuerdo haber tenido el mismo problema por una cubierta plástica transparente para audífonos. Si se exponía al sol o al flash en cierto ángulo, generaba ruido, pero nadie me creía
• En un “tiger cruise” usé una DV Cam sobre un portaaviones, y en cubierta el video se mezclaba raro cada 3 segundos. Coincidía exactamente con el período de barrido del radar. Intuí de inmediato que era por radiación, y al orientar la cámara para que la batería del celular (con metales pesados) quedara entre el radar y el cabezal magnético, el problema de cortes en el video desapareció por completo
• Dejo el enlace a la discusión de HN de ese momento https://news.ycombinator.com/item?id=9015663
• La depuración posterior en semiconductores flip-chip también puede hacerse apuntando un láser a un punto específico y detectando la luz reflejada para determinar si un transistor está encendido o apagado. Si aumentas la intensidad del láser, incluso puedes abrir o cerrar directamente ciertos transistores. Los semiconductores son sensibles a la luz por naturaleza, y por eso los chips se encapsulan en materiales opacos para protegerlos