How to use Claude to debug a wearable badge PCB
Claude Code built firmware for an ESP32 badge. Device checks and debug logs helped bring it up, but a human physically removed the switch causing a short.
Original prompt
Shared by the source author. See source notes for context.
Use graceful failover (i.e., proceed to next device if one fails, just report failure, but don't block).
Reach people exploring AI agents
See placements →What happened
Badge firmware ran and exposed its provisioning portal after a human removed the GPIO0-shorting switch and corrected the SDK environment. The account includes missed physical-design and debug-interpretation errors.
Reported by Federico Maggi — SubstackHow the agent did it
- Maggi supplied hardware specifications and asked for peripheral checks with graceful failover.
- Claude implemented firmware and helped inspect JTAG and OpenOCD output when the board would not boot.
- Maggi removed a shorting switch and corrected the SDK environment before verifying the running portal.
Where a person stepped in
Maggi provided authoritative KiCad details, inspected board behavior, physically removed a shorting switch and verified firmware on the badge.
Federico Maggi used Claude Code to implement firmware for a wearable conference badge after discussing its hardware architecture with ChatGPT. The badge combined an ESP32-S3, a charger, LED drivers and a multiplexer, with illuminated eyes and a scythe as its visible interface.
Maggi gave the agent hardware specifications and treated the KiCad design as the authoritative pin map. He first requested a barebones device check with graceful failover: a missing peripheral should be reported without blocking the next check. That staged approach separated board bring-up from production features such as LED patterns, buttons, Wi-Fi onboarding and a status webpage.
The physical board initially would not boot. A switch configuration grounded GPIO0, a problem missed by both the models and the human design review. Without a meter while travelling, Maggi used Claude's help with JTAG and OpenOCD logs, corrected an initially wrong register interpretation and eventually removed the offending switch himself.
Claude also needed an explicit correction to activate the current ESP-IDF environment before building. The eventual firmware ran and exposed its provisioning portal. The useful result was working badge firmware and a diagnosed boot fault; the account also shows why clean design exports and confident debugging suggestions did not replace checking actual component connections.
Prompt
Original prompt
Source: Substack · Federico Maggi
Frequently asked questions
Why start with device checks?
They exposed missing peripherals without blocking the rest of board bring-up.
What caused the boot failure?
A switch configuration grounded the ESP32-S3's GPIO0.
Was the repair autonomous?
No. Maggi interpreted physical connections and removed the switch himself.
More details
About this account
Maggi supplied hardware specifications and asked for peripheral checks with graceful failover. Claude implemented firmware and helped inspect JTAG and OpenOCD output when the board would not boot.
Original account opened. ChatGPT helped planning; Claude Code implemented and debugged firmware. Both models missed a physical switch short, and an initial debug-register interpretation was wrong. Original prompt excerpt.
Credit: Federico Maggi — Substack
Source published 4 Aug 2026
Source checked 14 Oct 2026
Tools and topics
Claude Code · ESP-IDF · KiCad · OpenOCD · ESP32-S3
Wearable electronics · Firmware debugging
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.