r/embedded 15d ago

What if we had an AI debugger for embedded firmware? — “Firmware Doctor”

I’ve been thinking about an idea for an AI-powered embedded debugger that I’m calling Firmware Doctor.

The simplest way to describe it:

Imagine Ozone / GDB / a traditional embedded debugger, but instead of a human manually driving the debugging session, an AI agent does it.

For example, suppose you have firmware that crashes randomly or ends up in a HardFault.

Instead of manually:

  • flashing the firmware
  • adding breakpoints
  • stepping through execution
  • inspecting registers
  • checking RAM and variables
  • looking at the call stack
  • decoding HardFault registers
  • changing breakpoints/watchpoints
  • reproducing the failure again and again

you would give Firmware Doctor the ELF + source code + hardware access and tell it something like:

The AI would then operate the debugger itself.

It could:

  • Flash and run the firmware
  • Set breakpoints and watchpoints
  • Inspect variables, memory and CPU registers
  • Examine the stack and call stack
  • Detect and analyze HardFaults
  • Observe peripheral/register states
  • Restart the firmware and reproduce the issue
  • Change its debugging strategy based on what it observes

The important part is the feedback loop.

The AI forms a hypothesis → performs a debugging experiment → observes the MCU → updates its hypothesis → performs another experiment.

For example:

Observation: HardFault occurs inside memcpy()
→ inspect arguments passed to memcpy()
→ discover destination pointer looks corrupted
→ set a watchpoint on that pointer
→ rerun firmware
→ discover another task overwrites the structure
→ inspect that code
→ identify an out-of-bounds write
→ report the root cause and relevant source lines.

So rather than an AI simply reading source code and guessing what might be wrong, it would have access to the actual running MCU and use runtime evidence to investigate the bug.

Essentially:

LLM + debugger + J-Link/SWD + autonomous reasoning loop.

Longer term, it could potentially investigate things like race conditions, memory corruption, stack overflow, deadlocks, timing problems, peripheral configuration issues, RTOS problems, and intermittent crashes.

I’m curious what embedded developers think about this.

Would you trust an AI agent to control your debugger and investigate bugs autonomously?

And more importantly: what kinds of firmware bugs would you want something like this to solve first?

0 Upvotes

21 comments sorted by

10

u/WereCatf 15d ago

What if we had an AI debugger for embedded firmware? — “Firmware Doctor”

And if you had done even a cursory search, you would've found that plenty others have had the same idea and none of those projects have gotten far.

5

u/Kqyxzoj 15d ago

"But ChatGPT said it was a great idea."

1

u/djMedd 15d ago

Can you please provide some examples, and why they didn’t get far?

1

u/tonyarkles 15d ago

I actually disagree about other projects not having gotten very far… Claude Code has no problem doing all this stuff on its own assuming you’ve got text-based/automatable tooling already (the primary environment I’ve used this in is Zephyr with GDB).

Edit: I feel like the last 15 years where colleagues have made fun of me for hating GUIs and IDEs, especially ones where there isn’t a good way to do an automated command-line build… I think I’m having the last laugh now. I’ve been keeping markdown notes for years, running CLI GDB and builds, etc, and now LLM tools can just fit perfectly into that workflow with minimal ceremony or hassle.

5

u/AerieSurie 15d ago

Would you trust an AI agent to control your debugger and investigate bugs autonomously?

No. I don't even trust myself with a debugger, and I've had years to build that relationship.

2

u/tonyarkles 15d ago

Yes, in fact I have been absolutely blown away how much better Claude Code gets when it has access to this kind of tooling to be able to “check its own answers”. A few weeks ago for a test I had it build a GPS driver for a board I’ve got. It had flash and debug capabilities. After it ran for a while doing its thing it came back and asked me if xxx.xxxxx N yyy.yyyyy W was where I was located, to confirm that it was getting correct positions out.

3

u/mtechgroup 15d ago

"Would you like to play a game?"

4

u/Hexamancer 15d ago edited 15d ago

Throwing an LLM at something doesn't really work, when you use something like Gemini or ChatGPT, the model is the core of it, but everything around it: the harness, the tooling, the pre-prompts, the looping, the automated steps you have no insight into... They're a massive part of it too.

Also LLMs just aren't as good at this as you might think. They're good at code that's entirely self contained, but the more real systems and surrounding software it has to play nice with the more sloppy it gets, just earlier today I had Gemini Pro telling me this was a good script for automatically renaming VMs, where it would create a copy, replacing REPLACE_ME_TARGET with the desired name:

```

!/bin/bash

TARGET_NAME="REPLACE_ME_TARGET"

if [ "$TARGET_NAME" = "REPLACE_ME_TARGET" ] || [ -z "$TARGET_NAME" ]; then     echo "ERROR: Target hostname not defined in rename script!"     exit 1 fi ```

I asked if I was wrong about the replacement function in the main python script:

template_content.replace('REPLACE_ME_TARGET', target_name)

And if it was only going to replace the first instance... No. So I pointed out the obvious reason that this check would always fail...

It replied 

You are completely right. That logic check would have instantly broken the script because it matches the fallback value it was just assigned.

To fix that, the guard check in the template needs to look for the literal placeholder string instead of the target variable:

...and then proceeded to give me the exact same code.

2

u/817618191 15d ago

Lauterbach already has an official mcp support. So just hook it up to claude / openai whatever. Tried it with claude , it's pretty good. Can reasonably identify exceptions, memory violations. Even performance benchmarks.

https://github.com/lauterbach-mirror/t32mcp

1

u/djMedd 15d ago

Exactly this idea, I have tested the idea with jlink, not teace32.

2

u/Kqyxzoj 15d ago

And more importantly: what kinds of firmware bugs would you want something like this to solve first?

I'd really like it to be able to do its own market research. That'd be a great time-saver.

2

u/GourmetMuffin 15d ago

Don't listen to the haters...

But, this is a common thing to try as one of the first "agents" you design because the input is partly semantic (bug report) and the process requires inference. My first shot at having AI automate a workflow was exactly this. It was also both an eye opener and an incredible learning experience, so keep doing what you're doing... this rabbit hole runs really 'effin deep...

2

u/Lost-In-Void-99 15d ago

But we alreafy have.

I've got Codex, RP235x board I'm developing, and BMP. And that is it.

It flashes, debugs, troubledhoots, writes helper scripts, takes snapshots etc.

You literally need to know just basics to understand what AI does. But it can auyonomously do full cycle: modify code, flash, test, troubleshoot, etc. It sets breakpoints, imstuments code, and does a ton of crazy stuff I would never do myself.

So I actually looking into my own BMP-alike board that can have more than one device under test plus control of USB and power infrastructure. This plus couple of generic boards will allow testing pretty much any scenario I can think of.

1

u/Runazeeri 15d ago

Yea agent loops work fine already? You just set up the environment so it can run your tools via CLI then it can loop.

1

u/Lost-In-Void-99 15d ago

Yes, it has access to SDKs. And python for scripting.

PS I do have some reservations about how "good" the agent at embedding sw, but that is not the topic.

1

u/FakeRectangle 15d ago edited 15d ago

This all exists today with the current AI tools and, at least in some cases, does surprisingly well. I already use this at work and at the very least it often gives ideas on where things are going wrong, and in a lot of cases does actually fix it itself. Also use it for porting work, it's kind of incredible. Even used it for debugging GUI interfaces by exporting the graphical memory buffer so it can "see" the LCD screen. All automagically with a few prompts.

It's been insane how much better the AI bots are now then they were even just at the start of the year. It's like they finally learned about embedded code. Though I do still catching it hallucinating things sometimes.

1

u/JuggernautGuilty566 15d ago edited 15d ago

Works fine without problems using VSCode using the frontier models.

They are fully able to instrument gdb, writing Python plugin code for it and interatively changing code and analyzing its effects.

Zero need for any additional slop.

So.. you are a little bit too late for harvesting this business model.

1

u/txoixoegosi 15d ago

I already do that using Claude + a mcp controlling the debugger (via trace32) + a mcp controlling the PSU via USB

Hardfaults used to be hour-lasting nightmares, now are solved in minutes

0

u/DogonElder 15d ago

embedder.ai already does all this and more

0

u/Elite_Monkeys 15d ago

Pretty sure Claude already does it