# ECU Debugging Methodology

Reduce uncertainty in layers: host installation, analyzer identity, physical
bus, transport, diagnostic protocol, ECU state, then firmware behavior. Do not
attribute a timeout to ECU firmware before eliminating the preceding layers.

## Investigation sequence

1. Preserve the initial symptom, time, ECU software identity, bench topology,
   power state, and reproduction steps.
2. Run doctor, enumerate stable channels, validate bench configuration, timing,
   termination, mode, and analyzer firmware. Reinitialize stale physical values.
3. Start with listen/read operations. Capture raw traffic before adding cyclic
   tasks, routes, replay, or diagnostic requests.
4. Read documented identity, software version, status, voltage/temperature, and
   DTC information. Treat an NRC as protocol evidence, not a generic timeout.
5. Correlate request/response timing, resets, BUSOFF, dropped traffic, and DTCs
   with firmware logs and source paths.
6. Introduce one controlled stimulus at a time. Retain a baseline capture and
   restore state after each experiment.
7. Preserve raw frames even when using DBC decoding. Confirm the DBC network and
   ECU variant before trusting signal names or engineering values.
8. Summarize evidence as observation, timestamp, command/capture, expected,
   actual, confidence, and likely firmware subsystem.

Use a bounded DID or DTC read for one-off inspection. Use `message send` only for
an explicitly defined frame, hardware TX tasks for accurate periodic stimuli,
and replay only after reviewing the capture for state-changing diagnostics and
correct channel/timing/flags. Query current help before composing any command.

Before UDS writes, routines, security access, DTC clearing, resets, or download,
confirm target identity and obtain authorization. Before programming, validate
artifact variant, segment map, checksum/signature, power, session/security,
bootloader preconditions, recovery path, and post-programming checks. Never
claim a firmware fix from a successful transfer without reconnecting and
re-running identity, DTC, communication, and symptom tests.

Analyzer firmware and ECU application firmware are different targets. Query
`device update --check` only after confirming the analyzer serial number. An
analyzer update interrupts every channel on that physical device and is not a
generic remedy for ECU communication faults; perform it only for a relevant
published fix and with explicit authorization.
