Skip to content

AI-Assisted Embedded Debugging: From Access to Evidence

AI can explain a log, but the last two error lines rarely establish a root cause in an embedded system. Give it controlled observation paths instead: collect evidence, form hypotheses, and design checks rather than declaring a conclusion from one symptom.

Build a bridge to the device

State how the device is connected, where the source and build output live, and what is allowed. Serial is best for U-Boot, early kernel output, and panics; ADB for Android properties, services, logcat, and dumpsys; SSH or a local terminal for Linux logs, processes, drivers, networking, and source. JTAG and lab instruments remain essential for CPU faults, bus timing, power, and reset.

If a device never reached userspace, preserve the complete serial boot log. Do not keep guessing through ADB or SSH. If an Android service fails, use the relevant properties, services, processes, and log buffers—not just the UI error.

Start read-only and state the boundary

Allow logs, system state, source, build configuration, and Git diffs. Require confirmation for code changes, rebooting, stopping services, flashing, module insertion/removal, and deletion. Commands such as dd, mkfs, fastboot erase, reboot, and bootloader environment changes deserve special care.

The device is connected through ADB; source and build output are local.
Collect information with read-only commands first. Do not edit, reboot, flash, or delete.
For each check, explain what it observes, the expected result, and what an abnormal result means.
Then list evidence, hypotheses, and the smallest next verification.

Match evidence to the failure stage

  • No boot: power, reset, clocks, serial, and JTAG.
  • Early boot: complete boot log, partition selection, device tree, kernel loading, and panic context.
  • Linux running: dmesg, journalctl, systemctl, modules, networking, and /proc.
  • Android running: getprop, logcat, dumpsys, services, HAL state, and SELinux denials.

Turn symptoms into a verifiable chain

For a missing I²C sensor node, inspect power/reset → controller → device address → device tree → driver match → probe → subsystem registration → userspace node. Pick one minimal check at each layer and keep each round small.

hypothesis → check → evidence → eliminate → narrow the scope

After resolution, record the symptom, environment, access path, evidence, root cause, change, verification, and rejected hypotheses—while removing sensitive identifiers. That turns one investigation into a reusable engineering note.