How Claude Code and I 'succeeded' our way into hardware damage

Pre-read note: This blog is hand written by me not AI, except the transcript section which Claudes own words.

Barnluren aims to be a simple and cost effective product that allows parents to bring a landline back into their home at a very low cost to allow children in 2026 to experience what voice only, screen free communication is like.

To deliver on this ambition we have to build quite a few components which range from the high level user experience - the buttons in the app, fonts and colors all the way down to the Linux Kernel modules that do the actual work to convert those cute voices into electrical signals that get passed to the physical phone handset. This story is about the very lowest level and how working with hardware can get interesting!

Analog Telephone Adapters (ATA)

An ATA is the bridge between digital and analog systems. Old school phones are all analog, they work by sending an analog signal much like a record player or tape player did. To talk to them from a regular smartphone or, to talk between them over the internet which is digital we have to convert the digital ones and zeroes to analog and back. I remember as teenager we had this device that was a cassette tape with a wire sticking out of it. You could put the cassete into the car stereo, and connect the wire to your Discman playing a digital CD, this is exactly the same thing the ATA does - but with a telephone.

Our goal is to build our own devices, we want a very simple device that you plug into the power, connect to your wifi, and the plug a real (hopefully reused) analog telephone into its single telephone port. Unfortunately such a device does not exist, but we found one that was similar enough, had the phone port but also a lot of other features and ports. We are using this as a test bed to build the lowest level of the software that runs the device, the firmware.

Our firmware will build on top of the excellent OpenWRT open source project. I will write another post on the beauty of Open Source Software later as this is absolutely key to enabling two people to build a product like Barnluren from the ground up. To get OpenWRT to work on a new device takes some poking at the hardware, and this is where we nearly started a fire!

Claude Code

If you don't know what Claude Code is, its important to understand for this story to make sense. Its a coding agent, it is very good at writing code in almost any language and has an encyclopedic knowledge of almost everything. Claude is really doing all the heavy lifting in this project, all the actual coding, deployment processes, server admin, debugging etc. So naturally, to reverse engineer how the hardware on the ATA we are using works so we can build our own Open Source version, Claude and I teamed up.

My role in the team is much like a coach / manager. I set the goals and objectives, claude helps me understand all the details, then we create a plan to achieve these together. Claude then does all the coding, scripting and testing on the devices. In this case I actually use two instances of Claude Code running side by side - Hands on Claude doing all the coding and connecting to the devices, and Coach Claude who I use to help me learn and to work on strategy and supervising Hands on Claude.

We were working through getting the high voltage circuits of the ATA working, this is what makes the phone bell ring. This process involves carefully studying what the device does when its running the standard firmware from the manufacturer and then implementing your own source code that repliciates this and seeing how the device behaves when you run your version. This reverse engineering process is hit and miss, it's like pressing all the buttons and seeing what happens until you have the full map.

We did not quite have the full map the first time we tested energizing that high voltage DCDC circuit so when we started it, the device started smoking! This is how the conversation with Claude went.

Hands on Claude and Coach Claude cannot talk to each other directly, I relay messages between them by copy pasting.

The hands-on Claude had just compiled and uploaded new code to the device and ran it over SSH. The code was attempting to start the high voltage DC-DC converter inside the telephone chip for the first time. I was watching the terminal output when the device suddenly rebooted.

Talking to the hands-on Claude:

Me: The device is rebooting. Did we fry it somehow?

Claude: No, we almost certainly didn't fry it. The device has a watchdog that reboots it automatically. What most likely happened: our code toggles GPIO pins from the kernel's hardware SPI to GPIO mode for our bit-bang SPI to the telephone chip. During the DC-DC powerup delays, the kernel likely tried to read from flash, found the SPI controller's pins stolen, and panicked. The device will boot normally — it has dual-boot failover.

Claude was confident it was just a watchdog reboot. Then I noticed something.

Me: Yes, it smells like burning.

The tone changed immediately.

Claude: Unplug the device immediately.

This is serious. What likely happened: with the register corruption fixed, the DC-DC converter actually started switching this time, but with potentially wrong parameters for your board's specific power topology. If the switch driver polarity is wrong, it can cause shoot-through in the FETs — both high-side and low-side conducting simultaneously — which burns components.

Me: The device is still in its case. So I cant easily see the components. Definitely smells like electronics burning.

Claude: We essentially "succeeded" our way into hardware damage. The previous runs never reached this point — the corrupted registers made it fail safely.

I'm sorry about this. Do you have a second FTA1101 device?

Meanwhile, I switched over to my coach Claude and shared what had just happened:

Me: Things got exciting!!!! (pasted the full transcript)

Coach Claude: That's a scary moment. The other Claude's analysis is spot on — with the registers now correct, the DC-DC converter actually tried to switch for the first time, and if any of the converter parameters are wrong for your board's specific power stage, you get destructive current.

Before doing anything else with DC-DC powerup again, the approach needs to change fundamentally: Read, don't guess. Boot the stock firmware and capture the actual runtime values while the converter is happily running. Not from disassembly, not from constants files — the actual live values from the working system. One wrong bit in the switch driver polarity and you get shoot-through.

I copied the coach's advice and pasted it back to the hands-on Claude:

Me: No worries! This is progress!! We have the one we need to unbrick with a UART cable. And then we have [some] more that arrived. It seems like we got to a point where we have to take a step back and start working with absolute certainty over what we are doing. Our advisor / coach Claude added this: (pasted the "Read, don't guess" advice)

Claude: Your advisor is absolutely right. This is genuinely progress — we proved the init sequence works. We just got ahead of ourselves on the most dangerous part.

Me: Yes, lets do it. Ill let the device cool off and have some lunch.

You have to crack eggs to make an Omelette

While this may sound a bit dangerous, and the thought of what could happen with AIs connected to IOT devices in our homes could do is a bit scary, it was neccessary to make progress. If I was doing this full process alone, I probably would have fried 10 devices before I worked it out. Im good with software in general but low level electronics like this is a challenge for me! The thing I find amazing is the speed at which you can iterate with the high level knowledge and using Claude to do all the details. We went from nothing to our own custom firmware running on device in a few days. In total we bricked 3 devices, device 2 was the one that nearly burned. Device 1 we bricked early by copying firmware that could not connect the network, so even though it was fine we had now way to talk to it anymore. Device 3 was also a bad firmware update. But with Claude's support...

Resurrection

We managed to open the cases of device 1 and 2 and with a special connector with 3 pins held against the circuit board, we could connect to the serial console. This is the built in last resort to communicate with the device. Once connected we could give them different instructions on how to start up. The full details here are a story for another day! Now, both devices are back to life and we are ploughing ahead with the next step of actually getting the audio to flow through them to real analog telephones.