Preparing automotive logs

Preparing automotive logs

Use this guide if you’re debugging a vehicle ECU, IVI head unit, digital cluster, ADAS module, or telematics control unit: CAN bus errors, VHAL property failures, AAOS crashes, BSP integration issues, OTA regressions.

Accepted log types

  • AAOS bugreports: .zip from adb bugreport on Android Automotive head units. Same format as mobile Android.
  • VHAL / CarService dumps: dumpsys car_service, dumpsys vehicle_hal_v2_0, and similar text dumps that capture vehicle HAL property events.
  • Kernel / BSP dmesg: kernel ring buffer for device-tree issues, thermal events, and driver probe failures.
  • CAN bus traces in candump format: text output from the open-source candump tool. This is the only CAN format auto-detected today.
  • DBC files: uploaded separately through the References library in the console (not as a log). Once registered, candump traces are decoded against your DBCs automatically.

For the full accepted/rejected list, see Supported file types.

Capturing CAN traces

candump (Linux SocketCAN): supported directly

If your bench or test rig runs Linux with SocketCAN:

# Bring up the interface (rate depends on the bus you're on)
sudo ip link set can0 type can bitrate 500000
sudo ip link set up can0

# Capture in logfile format (timestamped, machine-readable lines)
candump -L can0 > can0-trace.log

Upload can0-trace.log directly. Pair it with the relevant DBC file in the References library for decoded signal names.

Vector CANalyzer / CANoe, PEAK PCAN-View: convert first

Captures from Windows-side tools land as .blf, .asc, .trc, or .mf4. These binary or vendor-text variants are not auto-detected. Export to candump-format text before uploading:

  • Vector CANalyzer / CANoe: File → Export → choose a plaintext, log-style format with timestamps. If a candump exporter is unavailable in your version, a custom export script that emits (timestamp) interface canid#data per line will work.
  • PEAK PCAN-View: save the trace, then convert with can-utils-compatible tooling (e.g. log2asc / asc2log or a script that re-emits PCAN trace lines as candump).

The accepted line format is the standard candump output:

(1714820100.123456) can0 18FEF100#FFFFFFFF7DC8FF00

Capturing AAOS device logs

The same adb flow as mobile Android. From the head unit:

adb bugreport aaos-bugreport.zip
adb shell dumpsys car_service > car_service.txt
adb logcat -d > aaos-logcat.txt
adb shell dmesg > aaos-dmesg.txt

For full Android capture details see Preparing Android logs.

What’s not accepted

These are rejected in their native form. Convert to candump-format text first:

  • Vector: .blf, .asc
  • PEAK: .trc
  • ASAM: .mf4

Example questions to ask

Ask from the Research tab once the file is analyzed. Reach for Quick Search when you already know what you’re after, Deep Research when you need the root cause.

Quick Search for fast, cited lookups:

  • “Show all VHAL property changes around the navigation crash.”
  • “Which ECUs are transmitting?”
  • “Show messages on CAN ID 0x1A0.”
  • “Show the frames around the DTC.”

Deep Research for multi-step root-cause investigations:

  • “Why did the IVI reboot at 09:14?”
  • “What caused the VHAL timeout on PERF_VEHICLE_SPEED?”
  • “Correlate the CAN bus errors with the AP-side kernel events.”
  • “Trace the fault that set the diagnostic trouble code.”
  • “What preceded the bus-off event before the cluster went blank?”

See Quick Search and Deep Research for how the two modes differ.

Next

  • Deep Research: cross-ECU investigations across CAN, VHAL, dmesg, and logcat in a single report.
  • Delta Comparison: compare a passing build against a failing one across the same ECUs.
  • Quick Search: fast lookups when you know the CAN ID or the property name.