HardFaultHandler

Eyes on real hardware for your AI coding agent

Robots

Internet of Things

Artificial Intelligence

Visit WebsiteSee on Product Hunt

What problem does it solve? Every AI coding tool today writes embedded code the same way: it reasons about what should happen and hands you something that might work. It has no register state, no rail current, no GPIO timing, no idea whether the last flash even booted. It's guessing fluently. For web code that's survivable, because the agent runs the test, reads the error, and corrects itself. For firmware, there's no error to read, because nothing is watching the hardware. The loop is open, and the human is the sensor, manually reporting back what the board did. HardFault closes it — write, flash, observe, verify, roll back, against real silicon, with the observation step automated. The second problem is that embedded teams don't have any of the things software teams take for granted. No staging environment, no CI on every commit, no error tracking, no one-click rollback, no observability by default. So the discipline becomes: develop for months, get it very stable, only then put it in the field, because field iteration is so expensive it's effectively banned. That caution isn't rigour. It's a tooling deficit everyone learned to call rigour. Third, a dead field device is unrecoverable. It stops reporting and that's your entire signal. You can't tell dead from wedged, which are completely different fixes that look identical from the server. You can't see what happened in the minutes before it went quiet. You can't reflash it. Someone drives out, or the unit gets replaced, or it just stays dead — and with ten units in a pilot, a couple of bricks is the difference between a pilot that converts and one that quietly ends. Fourth, and this is the one nothing else catches: firmware that runs wrong without crashing. Crash tooling is mature and good — coredumps, fault handlers, watchdog traces. All of it keys off a failure signal. When there's no failure signal the whole category goes blind. The device reports idle, the rail says 82mA, and nothing in your stack notices the contradiction because nothing is holding those two facts next to each other. No crash, no log, no alert. It ships. Underneath all four is the same constraint. The moment you instrument firmware to catch an intermittent bug, timing shifts and the bug goes away — so HardFault sits outside the target entirely. No SDK, no code changes, nothing added to the device under investigation. It watches GPIO, ADC and power rails, reads CPU and register state over SWD/JTAG, tracks device life state across boot, run, sleep and fault, and pushes OTA with rollback and remote recovery. Then it cross-checks what the firmware claims against what the hardware is actually doing, and shows you the contradiction. --- How did your approach or process evolve? I built the wrong product first. V1 was a remote debug probe — flash it, poke it, read registers from anywhere. Useful, and not a reason for anyone to buy anything. The turn came when I stopped treating the power rail as another sensor channel and started treating it as a witness. Firmware can lie about its state. Current draw can't. The product stopped being remote access and became cross-checking the claim against the evidence, and everything else followed from that. Then AI agents changed the buyer without changing the product. I'd built an observation layer for humans, but what I'd actually built was a ground-truth source, and ground truth is exactly what an autonomous agent is missing. Same hardware, same measurements — except instead of a dashboard a human reads at 1am, it becomes a verification step in a loop that runs unattended. I kept it deliberately as a platform rather than an agent plugin. The measurement is the asset; the agent is one consumer of it. I also tried to sell before I could show. Cold outreach, careful targeting, rewritten copy, more lists. Zero replies, not one. I kept optimising the message when the real problem was that I was asking hardware engineers — the most evidence-driven people alive — to accept a claim with nothing to look at. No amount of copywriting fixes a missing artifact. I stopped outreach completely and went and built the demo instead. This launch is downstream of admitting that. And I stopped shipping to strangers. Early on I'd have handed a unit to anyone who said yes. Now it's an NDA first, a real commitment from the partner, eight weeks of structured feedback, and a named case study at the end. Fewer pilots, much deeper. The first unit is out with an IoT team in [Noida], and most of what's on the roadmap now came from that single engagement rather than from anything I planned. The meta-lesson is that I spent 3 months optimising the device and almost none on whether anyone would believe me. Those should have been the same project from day one. HardFault Handler sits outside your board as a battery-powered wireless device — no SDK, no code changes, nothing on the target. It captures GPIO, ADC and power rails, reads CPU and register state over SWD/JTAG, tracks device life state through boot, run, sleep and fault, and holds pre-event evidence so you're not guessing from a corpse. It tells a genuinely dead device apart from a wedged one, and it flashes, rolls back and recovers remotely, so a bad unit at a customer site doesn't mean a day of travel. Works with STM32, ESP32/ESP8266, Arduino/AVR, Silicon Labs EFR32, Nordic nRF52 and TI. The AI analysis is grounded in measurements the device took itself, which is also what makes it usable as the eyes for an AI coding agent — write, flash, observe, verify, roll back, against real silicon instead of a simulator. It's beta, and I want it kicked hard. Pilots ship as loaner hardware with no upfront cost. If you're bringing up hardware right now, tell me the last bug that cost you a week — the intermittent one, the one that vanished under the debugger, the one that only showed up in the field. I'd like to know whether this would have caught it, and I'm just as interested in the cases where it wouldn't.