Skip to content

vin: alternate functional and direct requests across attempts - #3721

Open
SpysyWeeb wants to merge 1 commit into
commaai:masterfrom
SpysyWeeb:vin-physical-standard-addrs
Open

vin: alternate functional and direct requests across attempts#3721
SpysyWeeb wants to merge 1 commit into
commaai:masterfrom
SpysyWeeb:vin-physical-standard-addrs

Conversation

@SpysyWeeb

Copy link
Copy Markdown

Some ECUs answer a request addressed to them and stay silent on the functional one, even for a data identifier they carry. The 2021 Hyundai Palisade instrument cluster at 0x7c6 on bus 0 is one: nothing to the functional UDS or OBD VIN requests on either bus, the full VIN to a UDS 22 F1 90 sent to it directly. Without a VIN the cached CarParams are never reused, so every ignition runs the full firmware query and its OBD multiplexing window.

The first attempt is unchanged. Retries send the request directly to STANDARD_VIN_ADDRS instead of functionally, so a direct request never shares a query with a functional one and an ECU that answers both cannot put two responses on one receiver. A car that answers the functional request never retries. No query is added and the startup timing refs are untouched; a retry, which today already means no VIN, sends one single frame per standard VIN address per request, plus a flow control frame for each ECU that answers. A first step toward the TODO: query physical addrs in get_vin, which stays.

Tests: test_fw_fingerprint.py gains a fake ISO-TP ECU: found only on the retry when it ignores the functional request, never addressed directly when it answers it, and a single direct request on the retry when it answers both but missed the first attempt. The timing test is unchanged.

Route (2021 Palisade, dongle ff9dba54b42b3afa): 0000004d--9a6fe8181a runs the full query (first ignition after an update) and finds the VIN on the retry: vin_rx_addr 0x7e8, so on this car the ECM at 0x7e0 answers the request addressed to it and not the functional one either; 00000051--39b47d07c0 is the next ignition on the cached CarParams. Once the VIN is cached, the next ignition hits the stale-params race in pandad's safety setter; commaai/openpilot#38780 fixes that.

🤖 Generated with Claude Code

Some ECUs answer a request addressed to them and stay silent on the
functional one, even for a data identifier they carry. The 2021 Hyundai
Palisade instrument cluster at 0x7c6 is one: no response to the
functional UDS or OBD VIN requests on buses 0 and 1, the full VIN to a
UDS 22 F1 90 sent to it directly on bus 0. Without a VIN the cached
CarParams are never reused, so every ignition runs the full firmware
query and its OBD multiplexing window.

The first attempt is unchanged. The next one sends the request directly
to the standard VIN addresses instead of functionally, and attempts keep
alternating from there. A direct request never shares a query with a
functional one, so an ECU that answers both cannot put two responses on
one receiver. A car that answers the functional request never retries,
no query is added and the startup timing refs are untouched.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Car behavior report

Replays driving segments through this PR and compares the behavior to master.
Please review any changes carefully to ensure they are expected.

✅ No changes detected

@github-actions github-actions Bot added the car related to opendbc/car/ label Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

car related to opendbc/car/

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant