Cómo Claude Code y yo 'triunfamos' hasta dañar el hardware

Nota previa: este artículo está escrito a mano por mí, no por una IA, salvo la sección de la transcripción, que son las palabras del propio Claude.

Barnluren quiere ser un producto sencillo y asequible que permita a los padres volver a tener un teléfono fijo en casa por muy poco dinero, para que los niños de 2026 puedan experimentar cómo es comunicarse solo con la voz, sin pantallas.

Para lograrlo tenemos que construir bastantes componentes, que van desde la experiencia de usuario de alto nivel (los botones de la app, las fuentes y los colores) hasta los módulos del kernel de Linux que hacen el trabajo real de convertir esas vocecitas en señales eléctricas que llegan al auricular del teléfono físico. Esta historia va del nivel más bajo de todos, ¡y de lo interesante que puede ponerse trabajar con hardware!

Adaptadores de teléfono analógico (ATA)

Un ATA es el puente entre los sistemas digitales y los analógicos. Los teléfonos de toda la vida son analógicos: funcionan enviando una señal analógica, igual que lo hacían un tocadiscos o un reproductor de casetes. Para hablar con ellos desde un smartphone normal, o para que hablen entre sí a través de internet (que es digital), hay que convertir los unos y ceros digitales en analógico y viceversa. Recuerdo que de adolescente teníamos un aparato que era una cinta de casete con un cable que le salía. Metías la cinta en la radio del coche y conectabas el cable a tu Discman, que reproducía un CD digital: eso es exactamente lo que hace el ATA, pero con un teléfono.

Nuestro objetivo es fabricar nuestros propios dispositivos: queremos un aparato muy sencillo que enchufas a la corriente, conectas a tu wifi y al que enchufas un teléfono analógico de verdad (a poder ser, reutilizado) en su único puerto telefónico. Por desgracia, ese dispositivo no existe, pero encontramos uno lo bastante parecido: tenía el puerto de teléfono, pero también muchas otras funciones y puertos. Lo estamos usando como banco de pruebas para construir el nivel más bajo del software que hace funcionar el dispositivo: el firmware.

Nuestro firmware se apoya en el excelente proyecto de código abierto OpenWRT. Más adelante escribiré otro artículo sobre lo maravilloso que es el software libre, porque es absolutamente clave para que dos personas puedan construir desde cero un producto como Barnluren. Hacer que OpenWRT funcione en un dispositivo nuevo exige trastear un poco con el hardware, ¡y ahí es donde casi provocamos un incendio!

Claude Code

Si no sabes qué es Claude Code, conviene entenderlo para que esta historia tenga sentido. Es un agente de programación: se le da muy bien escribir código en casi cualquier lenguaje y tiene un conocimiento enciclopédico de casi todo. En este proyecto, Claude hace realmente todo el trabajo pesado: toda la programación, los procesos de despliegue, la administración de servidores, la depuración, etc. Así que, como es natural, para hacer ingeniería inversa del hardware del ATA que usamos y poder construir nuestra propia versión de código abierto, Claude y yo formamos equipo.

Mi papel en el equipo es parecido al de un entrenador o un jefe de proyecto. Yo marco los objetivos y las metas, Claude me ayuda a entender todos los detalles y luego trazamos juntos un plan para conseguirlos. Después Claude hace toda la programación, los scripts y las pruebas en los dispositivos. En este caso, de hecho, uso dos instancias de Claude Code una al lado de la otra: el Claude manitas, que se encarga de programar y conectarse a los dispositivos, y el Claude entrenador, al que recurro para aprender, trabajar la estrategia y supervisar al Claude manitas.

Estábamos intentando poner en marcha los circuitos de alta tensión del ATA, que son los que hacen sonar el timbre del teléfono. El proceso consiste en estudiar con cuidado qué hace el dispositivo cuando ejecuta el firmware estándar del fabricante, implementar después tu propio código fuente que lo replique y ver cómo se comporta el dispositivo al ejecutar tu versión. Esta ingeniería inversa es un poco de prueba y error: es como pulsar todos los botones y ver qué pasa hasta tener el mapa completo.

No teníamos del todo el mapa completo la primera vez que probamos a energizar ese circuito DC-DC de alta tensión, así que cuando lo arrancamos, ¡el dispositivo empezó a echar humo! Así fue la conversación con Claude.

El Claude manitas y el Claude entrenador no pueden hablar entre ellos directamente; yo les paso los mensajes copiando y pegando.

El Claude manitas acababa de compilar y subir código nuevo al dispositivo y lo había ejecutado por SSH. El código intentaba arrancar por primera vez el convertidor DC-DC de alta tensión que hay dentro del chip telefónico. Yo estaba mirando la salida del terminal cuando, de repente, el dispositivo se reinició.

Hablando con el Claude manitas:

Yo: El dispositivo se está reiniciando. ¿Lo hemos frito de alguna manera?

Claude: No, es casi seguro que no lo hemos frito. El dispositivo tiene un watchdog que lo reinicia automáticamente. Lo más probable: nuestro código cambia los pines GPIO del SPI por hardware del kernel al modo GPIO para nuestro SPI bit-bang hacia el chip telefónico. Durante los retardos de encendido del DC-DC, el kernel seguramente intentó leer de la flash, se encontró con que los pines del controlador SPI estaban ocupados y entró en pánico. El dispositivo arrancará con normalidad: tiene failover de arranque dual.

Claude estaba convencido de que solo era un reinicio del watchdog. Entonces noté algo.

Yo: Sí, huele a quemado.

El tono cambió de inmediato.

Claude: Desenchufa el dispositivo ahora mismo.

Esto es serio. Lo que probablemente ha pasado: con la corrupción de registros corregida, esta vez el convertidor DC-DC ha empezado a conmutar de verdad, pero con parámetros posiblemente incorrectos para la topología de alimentación concreta de tu placa. Si la polaridad del driver de conmutación está invertida, puede provocar un shoot-through en los FET (que el lado alto y el lado bajo conduzcan a la vez), lo que quema componentes.

Yo: El dispositivo sigue en su carcasa, así que no puedo ver bien los componentes. Definitivamente huele a electrónica quemada.

Claude: Básicamente hemos "triunfado" hasta dañar el hardware. Las ejecuciones anteriores nunca llegaron a este punto: los registros corruptos hacían que fallara de forma segura.

Lo siento mucho. ¿Tienes un segundo dispositivo FTA1101?

Mientras tanto, cambié a mi Claude entrenador y le conté lo que acababa de pasar:

Yo: ¡¡¡¡La cosa se ha puesto emocionante!!!! (pegué la transcripción completa)

Claude entrenador: Es un momento que asusta. El análisis del otro Claude es acertadísimo: con los registros ya correctos, el convertidor DC-DC ha intentado conmutar de verdad por primera vez, y si alguno de los parámetros del convertidor no es el adecuado para la etapa de potencia concreta de tu placa, obtienes corrientes destructivas.

Antes de volver a tocar el encendido del DC-DC, el enfoque tiene que cambiar de raíz: Lee, no adivines. Arranca con el firmware original y captura los valores reales en tiempo de ejecución mientras el convertidor funciona sin problemas. No a partir del desensamblado ni de archivos de constantes: los valores vivos y reales del sistema que funciona. Un solo bit equivocado en la polaridad del driver de conmutación y tienes shoot-through.

Copié el consejo del entrenador y se lo pegué al Claude manitas:

Yo: ¡Sin problema! ¡¡Esto es progreso!! Tenemos el que hay que desbriquear con un cable UART. Y luego tenemos [algunos] más que acaban de llegar. Parece que hemos llegado a un punto en el que hay que dar un paso atrás y empezar a trabajar con certeza absoluta sobre lo que hacemos. Nuestro Claude asesor/entrenador añadió esto: (pegué el consejo de "Lee, no adivines")

Claude: Tu asesor tiene toda la razón. Esto es un progreso real: hemos demostrado que la secuencia de inicialización funciona. Simplemente nos adelantamos en la parte más peligrosa.

Yo: Sí, vamos a ello. Dejaré que el dispositivo se enfríe y me voy a comer.

Para hacer una tortilla hay que romper huevos

Aunque esto pueda sonar un poco peligroso, y la idea de lo que podrían hacer unas IA conectadas a dispositivos IoT en nuestras casas dé un poco de miedo, era necesario para avanzar. Si hubiera hecho todo este proceso solo, seguramente habría frito 10 dispositivos antes de resolverlo. Se me da bien el software en general, ¡pero la electrónica de bajo nivel como esta es todo un reto para mí! Lo que me parece increíble es la velocidad a la que puedes iterar teniendo el conocimiento de alto nivel y dejando que Claude se ocupe de todos los detalles. Pasamos de nada a tener nuestro propio firmware personalizado funcionando en el dispositivo en unos pocos días. En total briqueamos 3 dispositivos; el dispositivo 2 fue el que casi se quema. El dispositivo 1 lo briqueamos pronto al copiar un firmware que no podía conectarse a la red, así que, aunque estaba bien, ya no teníamos forma de comunicarnos con él. El dispositivo 3 también fue una mala actualización de firmware. Pero con el apoyo de Claude...

Resurrección

Conseguimos abrir las carcasas de los dispositivos 1 y 2 y, con un conector especial de 3 pines apoyado contra la placa, pudimos conectarnos a la consola serie. Es el último recurso integrado para comunicarse con el dispositivo. Una vez conectados, pudimos darles instrucciones distintas sobre cómo arrancar. ¡Los detalles completos son una historia para otro día! Ahora ambos dispositivos han vuelto a la vida y seguimos avanzando con el siguiente paso: conseguir que el audio fluya de verdad a través de ellos hasta teléfonos analógicos reales.