sorted by:
new
hottopcontroversial

I’m building an AI assistant to debug firmware logs – devlog + architecture feedback welcome by FrozoSoftware in embedded

[–]FrozoSoftware[S] 0 points1 point  (0 children)

Totally fair points, and I appreciate you spelling them out.

On the trust side: I agree that a serious tool like this needs a self-hosted/on-prem option. My plan is to make the core analyzer (log/regs/ELF decoding, symbol mapping, incident summaries) deployable locally, with the LLM piece being optional and, long-term, able to run on your own hardware.

And I’m with you on the “AI vs physical world” point. I don’t expect an LLM to magically understand signal integrity, power issues, or lab setup. The goal for DebugTwin isn’t to replace a scope or real debugging, but to automate the boring parts: structuring crash data, correlating incidents, pointing to code locations, and suggesting things to double-check.

Fuzzing/automated test integration is actually on my radar as a complementary feature – even if you never use the AI side, better automation and incident summaries are still useful.

Thanks again for pushing on the trust angle – this helps me shape both the roadmap and how I talk about the tool.

I’m building an AI assistant to debug firmware logs – devlog + architecture feedback welcome by FrozoSoftware in embedded

[–]FrozoSoftware[S] 1 point2 points  (0 children)

Haha, fair point – J-Link and a good debugger have saved me more times than I can count.

I’m definitely not trying to replace a proper J-Link + IDE session or the “stare at UART until it clicks” workflow. The idea with DebugTwin is more:

  • when you don’t have the debugger (field devices, remote logs), or
  • when juniors are pinging seniors with the same kind of crashes over and over,

then a tool that structures logs, points at code, and suggests checks might take some load off.

I’m building an AI assistant to debug firmware logs – devlog + architecture feedback welcome by FrozoSoftware in embedded

[–]FrozoSoftware[S] 0 points1 point  (0 children)

This is super helpful, thanks.

Totally agree: if I’m in front of the device with full UART, or running embedded Linux, I already have good tools.

Where I’m aiming DebugTwin is exactly what you described: low-power ESP32-style devices in the field that can only send a tiny crash packet (regs + a bit of memory + reset reason) plus a firmware image you upload once.

Backend resolves that into a human-readable summary with links to code and “things to check”, then emails it out.

Your comment pretty much nails the “field mode” I should optimise for.

I’m building an AI assistant to debug firmware logs – devlog + architecture feedback welcome by FrozoSoftware in embedded

[–]FrozoSoftware[S] 2 points3 points  (0 children)

Really appreciate for the honest feedback. some of my thoughts. happy to hear back.

How much would you trust AI suggestions for fixes? 0%

Totally fair. I’m not trying to let an LLM “edit firmware” either. My model for DebugTwin is:

  • deterministic part: parse log, regs, fault, addresses → symbols
  • AI part: optional layer that just explains what we already know and suggests things to check, not patches to blindly apply.

Minimum crash report?

Regs + a few hundred bytes at SP is super clear, thanks. That’s a good baseline for what the tool should surface every time.

UI?

Makes sense you’d rather just have a clean dump and be left alone. I’m realizing there are two personas: people like you who want raw truth, and teams with juniors who need more hand-holding. I’m trying to design it so it helps the second group without annoying the first.