Correlate fragmented evidence
Connect log messages, hardware symptoms, protocol failures, and runtime events instead of treating each signal in isolation.
Embedded diagnostics, accelerated
Find the root cause behind device failures.
DebugArc helps embedded engineers turn firmware logs, crash traces, device telemetry, and hardware symptoms into structured diagnostic reports powered by Claude.
Firmware & RTOS logs
I²C / SPI / UART faults
Structured root-cause reports
00:00.114 [BOOT] Device start
00:00.187 [INFO] Initializing I2C bus
00:00.201 [INFO] MPU6050 address 0x68
00:00.318 [ERROR] I2C timeout at 0x68
00:00.326 [ERROR] WHO_AM_I returned 0x00
00:00.711 [WARN] Retry 2/3 failed
Diagnostic signal identified
HIGH CONFIDENCESubsystemI²C / IMU sensor
Likely causeBus-level communication fault
STM32ESP32FreeRTOSUARTI²CSPIHardFaultWatchdogSensor telemetry
Why DebugArc
Debug the system, not just the error line.
Embedded failures rarely live in one layer. DebugArc brings firmware output, bus symptoms, runtime context, and engineering evidence into one diagnostic workflow.
Prioritize likely root causes
Separate symptoms from causes and rank the checks that are most likely to reduce uncertainty quickly.
Turn analysis into action
Get a structured troubleshooting sequence with evidence, hypotheses, recommended measurements, and a clear next action.
Workflow
From raw logs to a diagnostic path.
Designed for early investigations when engineers need a fast, explainable starting point before deeper bench work.
Capture
Paste UART output, crash traces, compiler errors, device telemetry, or a plain-language hardware symptom.
Analyze
DebugArc sends the engineering context through a constrained Claude diagnostic workflow.
Diagnose
Evidence is organized into likely root causes, confidence, subsystem, and alternative hypotheses.
Resolve
Follow a prioritized verification sequence and feed new measurements back into the investigation.
Structured reasoning
Reports engineers can inspect, not black-box answers.
Every result is organized around the engineering question: what failed, what evidence supports it, what else could explain it, and what should you measure next?
✓Subsystem detection and severity classification
✓Evidence-linked root-cause hypothesis
✓Alternative causes ranked by plausibility
✓Concrete bench checks and next action
Diagnostic reportHIGH CONFIDENCE
Likely root cause
MCU is not receiving a valid response from the IMU on the I²C bus.
Evidence
- Address 0x68 times out.
- WHO_AM_I returns 0x00.
- Retries fail consistently.
Recommended checks
- Verify sensor supply and ground.
- Run I²C address scan.
- Measure SDA/SCL idle level.
- Inspect bus with logic analyzer.
“The goal is not to replace the engineer. It is to shorten the path from an ambiguous failure to the next useful measurement.”
input → firmware log + target context
classify → subsystem + severity
reason → root-cause hypothesis
validate → evidence + alternatives
output → structured diagnostic report
model: claude-sonnet-5-5
format: constrained JSON schema
Built with Claude
Claude is the reasoning layer.
DebugArc uses Claude to reason across mixed engineering context and return a predictable report schema that the product can render and evaluate.
The API key stays server-side in Cloudflare. DebugArc's browser client never exposes Anthropic credentials.
Early MVP
Bring a failure. Leave with a debugging path.
Try the interactive diagnostic demo with a sample embedded-system log. When the Claude API is connected, the same interface runs live analysis.
Open the DebugArc demo →