Hur Claude Code och jag 'lyckades' oss fram till hårdvaruskador
Intressanta saker händer när AI och verklig hårdvara möts!
Av Greg Chrystall
Förord: Det här inlägget är handskrivet av mig, inte av AI – förutom transkriptionsdelen, som är Claudes egna ord.
Barnluren ska vara en enkel och prisvärd produkt som låter föräldrar ta tillbaka en hemtelefon i hemmet till en mycket låg kostnad, så att barn år 2026 får uppleva hur kommunikation med enbart röst – helt utan skärm – känns.
För att nå dit måste vi bygga ganska många komponenter, från den övergripande användarupplevelsen – knapparna i appen, typsnitt och färger – hela vägen ner till de Linux-kärnmoduler som gör det faktiska jobbet: att omvandla de där söta rösterna till elektriska signaler som skickas vidare till den fysiska telefonluren. Den här berättelsen handlar om den allra lägsta nivån, och om hur intressant det kan bli att jobba med hårdvara!
Analoga telefonadaptrar (ATA)
En ATA är bryggan mellan digitala och analoga system. Gamla telefoner är helt analoga: de fungerar genom att skicka en analog signal, ungefär som en skivspelare eller bandspelare gjorde. För att kunna prata med dem från en vanlig smartphone, eller låta dem prata med varandra över internet (som är digitalt), måste vi omvandla de digitala ettorna och nollorna till analoga signaler och tillbaka igen. Jag minns att vi som tonåringar hade en sådan där pryl som såg ut som ett kassettband med en sladd som stack ut. Man stoppade kassetten i bilstereon och kopplade sladden till sin Discman som spelade en digital CD – det är exakt samma sak som en ATA gör, fast med en telefon.
Vårt mål är att bygga våra egna enheter: en mycket enkel apparat som du kopplar in i eluttaget, ansluter till ditt wifi och sedan pluggar in en riktig (helst återanvänd) analog telefon i dess enda telefonport. Tyvärr finns ingen sådan enhet, men vi hittade en som var tillräckligt lik – den hade telefonporten, men också en massa andra funktioner och portar. Vi använder den som testbädd för att bygga den lägsta nivån av mjukvaran som kör enheten: den inbyggda programvaran, firmware.
Vår firmware bygger ovanpå det utmärkta open source-projektet OpenWRT. Jag ska skriva ett separat inlägg om det fina med öppen källkod längre fram, för det är helt avgörande för att två personer ska kunna bygga en produkt som Barnluren från grunden. Att få OpenWRT att fungera på en ny enhet kräver en del pillande med hårdvaran – och det var där vi nästan startade en brand!
Claude Code
Om du inte vet vad Claude Code är, så behöver du veta det för att den här berättelsen ska hänga ihop. Det är en kodagent: den är mycket bra på att skriva kod i nästan vilket språk som helst och har encyklopedisk kunskap om nästan allt. Claude gör verkligen allt det tunga arbetet i det här projektet – all faktisk kodning, driftsättning, serveradministration, felsökning och så vidare. Så när vi skulle bakåtkonstruera hur hårdvaran i ATA:n vi använder fungerar, för att kunna bygga vår egen open source-version, slog Claude och jag oss naturligtvis ihop.
Min roll i teamet är ungefär som en coach eller manager. Jag sätter mål och riktning, Claude hjälper mig förstå alla detaljer, och sedan gör vi upp en plan tillsammans för att nå dit. Claude gör därefter all kodning, alla skript och all testning på enheterna. I det här fallet använder jag faktiskt två instanser av Claude Code sida vid sida: Hands-on-Claude, som sköter all kodning och kopplar upp sig mot enheterna, och Coach-Claude, som jag använder för att lära mig, jobba med strategi och övervaka Hands-on-Claude.
Vi höll på att få igång högspänningskretsarna i ATA:n – det är de som får telefonens ringklocka att ringa. Processen går ut på att noggrant studera vad enheten gör när den kör tillverkarens standardfirmware, sedan skriva egen källkod som replikerar det och se hur enheten beter sig när man kör sin egen version. Sådan bakåtkonstruktion är lite av ett lotteri – det är som att trycka på alla knappar och se vad som händer tills man har hela kartan.
Vi hade inte riktigt hela kartan första gången vi testade att aktivera den där DC/DC-högspänningskretsen, så när vi startade den började enheten ryka! Så här gick samtalet med Claude.
Hands-on-Claude och Coach-Claude kan inte prata direkt med varandra – jag förmedlar meddelanden mellan dem genom att kopiera och klistra in.
Hands-on-Claude hade precis kompilerat och laddat upp ny kod till enheten och kört den över SSH. Koden försökte för första gången starta DC/DC-högspänningsomvandlaren inuti telefonchipet. Jag satt och tittade på terminalutskriften när enheten plötsligt startade om.
I samtal med Hands-on-Claude:
Jag: Enheten startar om. Grillade vi den på något sätt?
Claude: Nej, vi har nästan säkert inte grillat den. Enheten har en watchdog som startar om den automatiskt. Det som troligen hände: vår kod växlar GPIO-pinnarna från kärnans hårdvaru-SPI till GPIO-läge för vår bit-bang-SPI mot telefonchipet. Under fördröjningarna vid DC/DC-uppstarten försökte kärnan sannolikt läsa från flashminnet, upptäckte att SPI-styrkretsens pinnar var tagna och fick panik. Enheten kommer att starta normalt – den har dual-boot-failover.
Claude var säker på att det bara var en watchdog-omstart. Sedan lade jag märke till något.
Jag: Ja, det luktar bränt.
Tonen ändrades omedelbart.
Claude: Dra ur sladden till enheten omedelbart.
Det här är allvarligt. Det som troligen hände: när registerkorruptionen väl var åtgärdad började DC/DC-omvandlaren faktiskt switcha den här gången, men med potentiellt fel parametrar för just ditt korts strömtopologi. Om polariteten på switchdrivaren är fel kan det orsaka shoot-through i FET:arna – att både hög- och lågsidan leder samtidigt – vilket bränner komponenter.
Jag: Enheten sitter fortfarande i sitt hölje, så jag kan inte se komponenterna så lätt. Det luktar definitivt bränd elektronik.
Claude: Vi "lyckades" oss i praktiken fram till hårdvaruskador. De tidigare körningarna kom aldrig så här långt – de korrupta registren gjorde att det fallerade på ett säkert sätt.
Jag är ledsen för det här. Har du en andra FTA1101-enhet?
Under tiden bytte jag över till min Coach-Claude och delade vad som just hade hänt:
Jag: Nu blev det spännande!!!! (klistrade in hela transkriptionen)
Coach-Claude: Det där är ett läskigt ögonblick. Den andra Claudes analys är helt rätt – med registren nu korrekta försökte DC/DC-omvandlaren faktiskt switcha för första gången, och om någon av omvandlarens parametrar är fel för just ditt korts effektsteg får du destruktiva strömmar.
Innan ni gör något mer med DC/DC-uppstarten behöver angreppssättet ändras i grunden: Läs, gissa inte. Boota med originalfirmware och fånga de faktiska körtidsvärdena medan omvandlaren går som den ska. Inte från disassemblering, inte från konstantfiler – de faktiska levande värdena från det fungerande systemet. En enda fel bit i switchdrivarens polaritet och du får shoot-through.
Jag kopierade coachens råd och klistrade in det hos Hands-on-Claude:
Jag: Ingen fara! Det här är framsteg!! Vi har den vi behöver återuppliva med en UART-kabel. Och sedan har vi [några] till som har kommit. Det känns som att vi har nått en punkt där vi måste ta ett steg tillbaka och börja jobba med absolut säkerhet kring vad vi gör. Vår rådgivare/coach-Claude tillade det här: (klistrade in rådet "Läs, gissa inte")
Claude: Din rådgivare har helt rätt. Det här är verkligen framsteg – vi bevisade att init-sekvensen fungerar. Vi gick bara händelserna i förväg på den farligaste delen.
Jag: Ja, vi kör på det. Jag låter enheten svalna och äter lite lunch.
Man måste knäcka ägg för att göra omelett
Det här kan låta lite farligt, och tanken på vad AI kopplad till IoT-prylar i våra hem skulle kunna ställa till med är onekligen lite skrämmande – men det var nödvändigt för att komma framåt. Om jag hade gjort hela den här processen på egen hand hade jag förmodligen grillat 10 enheter innan jag fått ordning på det. Jag är rätt bra på mjukvara i allmänhet, men lågnivåelektronik som det här är en utmaning för mig! Det jag tycker är fantastiskt är hastigheten man kan iterera i när man har den övergripande kunskapen och låter Claude sköta alla detaljer. Vi gick från ingenting till egen anpassad firmware på enheten på några dagar. Totalt brickade vi 3 enheter – enhet 2 var den som nästan brann upp. Enhet 1 brickade vi tidigt genom att kopiera in firmware som inte kunde ansluta till nätverket, så även om den i sig var hel hade vi inte längre något sätt att prata med den. Enhet 3 var också en dålig firmware-uppdatering. Men med Claudes hjälp...
Återuppståndelse
Vi lyckades öppna höljena på enhet 1 och 2, och med en särskild kontakt med 3 stift som hölls mot kretskortet kunde vi ansluta till seriekonsolen. Det är enhetens inbyggda sista utväg för kommunikation. Väl anslutna kunde vi ge dem andra instruktioner om hur de skulle starta. Alla detaljer är en historia för en annan dag! Nu lever båda enheterna igen och vi plöjer vidare med nästa steg: att faktiskt få ljudet att flöda genom dem till riktiga analoga telefoner.