Wie Claude Code und ich uns mit lauter „Erfolgen“ einen Hardwareschaden eingehandelt haben

Vorab: Diesen Blogbeitrag habe ich selbst geschrieben, nicht eine KI – mit Ausnahme des Transkripts, das sind Claudes eigene Worte.

Barnluren soll ein einfaches und kostengünstiges Produkt sein, mit dem Eltern für sehr wenig Geld ein Festnetztelefon zurück ins Haus holen können – damit Kinder im Jahr 2026 erleben, wie sich Kommunikation nur mit der Stimme, ganz ohne Bildschirm, anfühlt.

Um diesen Anspruch einzulösen, müssen wir eine ganze Reihe von Bausteinen bauen: von der obersten Ebene der Nutzererfahrung – den Buttons in der App, Schriften und Farben – bis hinunter zu den Linux-Kernel-Modulen, die die eigentliche Arbeit machen und diese niedlichen Stimmen in elektrische Signale umwandeln, die an den echten Telefonhörer gehen. Diese Geschichte handelt von der allertiefsten Ebene – und davon, wie spannend die Arbeit mit Hardware werden kann!

Analoge Telefonadapter (ATA)

Ein ATA ist die Brücke zwischen digitalen und analogen Systemen. Telefone der alten Schule sind durch und durch analog: Sie senden ein analoges Signal, ganz ähnlich wie früher ein Plattenspieler oder ein Kassettenrekorder. Damit ein normales Smartphone mit ihnen sprechen kann – oder damit zwei von ihnen übers Internet miteinander sprechen können, das ja digital ist – müssen wir die digitalen Einsen und Nullen in analoge Signale umwandeln und wieder zurück. Ich erinnere mich, dass wir als Teenager so ein Ding hatten: eine Kassette mit einem Kabel dran. Die Kassette kam ins Autoradio, das Kabel in den Discman, der eine digitale CD abspielte. Genau das macht ein ATA – nur eben mit einem Telefon.

Unser Ziel ist es, eigene Geräte zu bauen. Wir wollen ein sehr einfaches Gerät: einstecken, mit dem WLAN verbinden und ein echtes (am besten wiederverwendetes) analoges Telefon in die einzige Telefonbuchse stecken. Leider gibt es so ein Gerät nicht. Aber wir haben eines gefunden, das ähnlich genug ist: mit Telefonbuchse, dafür aber auch mit vielen weiteren Funktionen und Anschlüssen. Wir nutzen es als Testumgebung, um die unterste Softwareebene des Geräts zu bauen – die Firmware.

Unsere Firmware baut auf dem hervorragenden Open-Source-Projekt OpenWRT auf. Über die Schönheit von Open-Source-Software schreibe ich später noch einen eigenen Beitrag, denn sie ist absolut entscheidend dafür, dass zwei Leute ein Produkt wie Barnluren von Grund auf bauen können. Damit OpenWRT auf einem neuen Gerät läuft, muss man allerdings ein bisschen an der Hardware herumstochern – und genau dabei hätten wir beinahe einen Brand ausgelöst!

Claude Code

Falls du nicht weißt, was Claude Code ist: Für diese Geschichte ist das wichtig. Es ist ein Coding-Agent. Er schreibt sehr guten Code in fast jeder Sprache und hat ein enzyklopädisches Wissen über fast alles. Claude macht in diesem Projekt wirklich die ganze Schwerarbeit: das eigentliche Programmieren, die Deployment-Prozesse, Serveradministration, Debugging und so weiter. Also haben Claude und ich uns natürlich zusammengetan, um die Hardware des ATA, den wir verwenden, zu reverse-engineeren und daraus unsere eigene Open-Source-Variante zu bauen.

Meine Rolle im Team ist eher die von Coach und Manager. Ich setze die Ziele, Claude hilft mir, alle Details zu verstehen, und gemeinsam machen wir einen Plan, wie wir dorthin kommen. Claude übernimmt dann das Programmieren, die Skripte und die Tests auf den Geräten. In diesem Fall habe ich sogar zwei Instanzen von Claude Code parallel laufen lassen: Hands-on-Claude, der den ganzen Code schreibt und sich mit den Geräten verbindet, und Coach-Claude, mit dem ich lerne, Strategie mache und Hands-on-Claude beaufsichtige.

Wir waren gerade dabei, die Hochspannungsschaltungen des ATA zum Laufen zu bringen – die sorgen dafür, dass die Telefonklingel klingelt. Dabei schaut man sich sehr genau an, was das Gerät mit der Original-Firmware des Herstellers tut, schreibt dann eigenen Code, der das nachbildet, und beobachtet, wie sich das Gerät mit der eigenen Version verhält. Dieses Reverse Engineering ist Versuch und Irrtum: Man drückt alle Knöpfe und schaut, was passiert, bis man die ganze Karte hat.

Beim ersten Versuch, diese Hochspannungs-DCDC-Schaltung zu aktivieren, hatten wir die Karte noch nicht ganz – und als wir sie starteten, fing das Gerät an zu rauchen! So lief das Gespräch mit Claude ab.

Hands-on-Claude und Coach-Claude können nicht direkt miteinander reden; ich gebe die Nachrichten per Copy-and-paste weiter.

Der Hands-on-Claude hatte gerade neuen Code kompiliert, aufs Gerät geladen und über SSH gestartet. Der Code versuchte zum ersten Mal, den Hochspannungs-DC-DC-Wandler im Telefonchip hochzufahren. Ich schaute auf die Terminalausgabe, als das Gerät plötzlich neu startete.

Gespräch mit dem Hands-on-Claude:

Ich: Das Gerät startet neu. Haben wir es irgendwie gegrillt?

Claude: Nein, mit ziemlicher Sicherheit nicht. Das Gerät hat einen Watchdog, der es automatisch neu startet. Was wahrscheinlich passiert ist: Unser Code schaltet GPIO-Pins vom Hardware-SPI des Kernels in den GPIO-Modus um, damit wir per Bit-Banging mit dem Telefonchip sprechen können. Während der Wartezeiten beim DC-DC-Hochfahren hat der Kernel vermutlich versucht, aus dem Flash zu lesen, die Pins des SPI-Controllers als „gestohlen“ vorgefunden und eine Kernel Panic ausgelöst. Das Gerät wird normal booten – es hat ein Dual-Boot-Failover.

Claude war sich sicher, dass es nur ein Watchdog-Neustart war. Dann fiel mir etwas auf.

Ich: Ja, es riecht verbrannt.

Der Ton änderte sich sofort.

Claude: Zieh sofort den Stecker.

Das ist ernst. Was wahrscheinlich passiert ist: Nachdem die Registerfehler behoben waren, hat der DC-DC-Wandler diesmal tatsächlich angefangen zu schalten – möglicherweise aber mit falschen Parametern für die konkrete Leistungstopologie deines Boards. Wenn die Polarität des Switch-Treibers falsch ist, kann es zu Querströmen (Shoot-through) in den FETs kommen – High-Side und Low-Side leiten gleichzeitig – und das verbrennt Bauteile.

Ich: Das Gerät ist noch im Gehäuse, ich kann die Bauteile also nicht einfach sehen. Aber es riecht eindeutig nach verbrannter Elektronik.

Claude: Wir haben uns im Grunde zum Hardwareschaden „durchgearbeitet“. Die vorherigen Durchläufe sind nie so weit gekommen – die fehlerhaften Register haben dafür gesorgt, dass es gefahrlos scheiterte.

Das tut mir leid. Hast du ein zweites FTA1101-Gerät?

Parallel dazu bin ich zu meinem Coach-Claude gewechselt und habe ihm erzählt, was gerade passiert war:

Ich: Es wurde gerade spannend!!!! (komplettes Transkript eingefügt)

Coach-Claude: Das ist ein beängstigender Moment. Die Analyse des anderen Claude trifft es genau: Jetzt, wo die Register stimmen, hat der DC-DC-Wandler zum ersten Mal wirklich versucht zu schalten. Und wenn auch nur einer der Wandlerparameter nicht zur konkreten Leistungsstufe deines Boards passt, bekommst du zerstörerische Ströme.

Bevor du noch einmal irgendetwas mit dem DC-DC-Hochfahren machst, muss sich der Ansatz grundlegend ändern: Lesen, nicht raten. Boote die Original-Firmware und zeichne die tatsächlichen Laufzeitwerte auf, während der Wandler fröhlich läuft. Nicht aus dem Disassembly, nicht aus Konstantendateien – die echten Live-Werte aus dem funktionierenden System. Ein falsches Bit in der Polarität des Switch-Treibers und du hast Shoot-through.

Ich habe den Rat des Coaches kopiert und beim Hands-on-Claude eingefügt:

Ich: Kein Problem! Das ist Fortschritt!! Wir haben noch das Gerät, das wir mit einem UART-Kabel wiederbeleben müssen. Und es sind [einige] weitere angekommen. Es sieht so aus, als wären wir an dem Punkt, an dem wir einen Schritt zurücktreten und mit absoluter Gewissheit arbeiten müssen. Unser Berater/Coach-Claude hat das hier ergänzt: (der „Lesen, nicht raten“-Rat eingefügt)

Claude: Dein Berater hat völlig recht. Das ist wirklich Fortschritt – wir haben bewiesen, dass die Init-Sequenz funktioniert. Wir sind beim gefährlichsten Teil nur zu schnell vorgeprescht.

Ich: Ja, machen wir das. Ich lasse das Gerät abkühlen und gehe erst mal Mittag essen.

Wo gehobelt wird, fallen Späne

Das klingt vielleicht etwas gefährlich, und der Gedanke daran, was KIs mit vernetzten Geräten in unseren Wohnungen anstellen könnten, ist schon ein bisschen beunruhigend – aber es war nötig, um voranzukommen. Hätte ich den ganzen Prozess allein gemacht, hätte ich wahrscheinlich 10 Geräte gegrillt, bevor ich es herausgefunden hätte. Mit Software kenne ich mich allgemein gut aus, aber hardwarenahe Elektronik wie diese ist eine echte Herausforderung für mich! Was ich beeindruckend finde, ist das Tempo, in dem man mit dem Überblickswissen vorankommt, wenn Claude die Details übernimmt. Wir sind in wenigen Tagen von null zu einer eigenen Firmware gekommen, die auf dem Gerät läuft. Insgesamt haben wir 3 Geräte gebrickt. Gerät 2 war das, das beinahe abgebrannt wäre. Gerät 1 haben wir früh gebrickt, indem wir eine Firmware aufgespielt haben, die keine Netzwerkverbindung aufbauen konnte – es war also eigentlich in Ordnung, nur konnten wir nicht mehr mit ihm sprechen. Gerät 3 war ebenfalls ein misslungenes Firmware-Update. Aber mit Claudes Hilfe …

Wiederbelebung

Wir haben es geschafft, die Gehäuse von Gerät 1 und 2 zu öffnen und mit einem speziellen Stecker mit 3 Pins, den wir gegen die Platine gedrückt haben, eine Verbindung zur seriellen Konsole herzustellen. Das ist die eingebaute letzte Rettung, um mit dem Gerät zu kommunizieren. Einmal verbunden, konnten wir ihnen andere Startanweisungen geben. Die Details dazu sind eine Geschichte für ein andermal! Jetzt sind beide Geräte wieder am Leben, und wir arbeiten am nächsten Schritt: den Ton tatsächlich durch sie hindurch zu echten analogen Telefonen fließen zu lassen.