Hyundai: VIN request fails on some cars

[sunnyhaibin]

Describe the bug

We are working on a car port for a 2022 Hyundai Kona Electric (#23517), and the car will not get recognized and kept throwing "CAN Error" as soon as it goes onroad. Upon investigation, we found that the car's VIN wasn't even read correctly: OSEV__ BMS \x00\x00\x00\x00\x00\x00. We attempted with multiple power cycles and the issue persisted.

We then attempted to introduce a delay with the fingerprinting query similar to how Subaru is trying to do, and found that the VIN was changed to 00000000000000000, but broken or unqueried FW versions all over the place.

Maybe this is somewhat related to the inconsistent fingerprinting we had issues with a couple of months ago? (#21333)

Bad VIN, fully queried FW versions (unconfirmed):

• 248133d966e0182c|2022-01-14--05-28-05
• 248133d966e0182c|2022-01-14--04-01-46

{'carFingerprint': 'HYUNDAI KONA ELECTRIC 2022',
               'carFw': [{'address': 1988,
                          'ecu': 'fwdCamera',
                          'fwVersion': b'\xf1\x00OSP LKA  AT CND LHD 1.00 1.02 99211-J9110 802',
                          'subAddress': 0},
                         {'address': 2001,
                          'ecu': 'esp',
                          'fwVersion': b'\xf1\x8758520-K4010\xf1\x00OS IEB \x02 101 \x11\x13 58520-K4010',
                          'subAddress': 0},
                         {'address': 2004, 'ecu': 'eps', 'fwVersion': b'\xf1\x00OSP MDPS C 1.00 1.02 56310K4260\x00 4OEPC102', 'subAddress': 0},
                         {'address': 2000,
                          'ecu': 'fwdRadar',
                          'fwVersion': b'\xf1\x00YB__ FCA -----      1.00 1.01 99110-K4500      \x00\x00\x00',
                          'subAddress': 0}],
               'carName': 'hyundai',
               'carVin': 'OSEV__ BMS \x00\x00\x00\x00\x00\x00',

00000000000000000 VIN, but broken/unqueried FW versions:

• 248133d966e0182c|2022-01-14--05-09-54
• 248133d966e0182c|2022-01-14--04-56-48

{'carParams': {'carFingerprint': 'mock',
               'carFw': [{'address': 2000,
                          'ecu': 'fwdRadar',
                          'fwVersion': b'\xf1\x00YB__ FCA -----      1.00 1.01 99110-K4500      \x00\x00\x00',
                          'subAddress': 0}],
               'carName': 'mock',
               'carVin': '00000000000000000',

What hardware does this issue affect?

comma two

Which car does this affect?

Hyundai Kona Electric 2022

Provide a route where the issue occurs

248133d966e0182c|2022-01-14--05-28-05

openpilot version

0.8.13

Additional info

No response

[pd0wm]

I looked into this for that other issue a while back. In case of a bad VIN I think this is a bug in the ECU itself. It probably copies the VIN to some area in RAM when initializing. If you query the VIN too quickly after boot you get exactly 17 bytes of garbage data. If you look at the raw CAN traffic everything looks fine (except for the weird contents) and there are no errors.

If you wait long enough, does the VIN eventually return something sane?

[sunnyhaibin]

I looked into this for that other issue a while back. In case of a bad VIN I think this is a bug in the ECU itself. It probably copies the VIN to some area in RAM when initializing. If you query the VIN too quickly after boot you get exactly 17 bytes of garbage data. If you look at the raw CAN traffic everything looks fine (except for the weird contents) and there are no errors.

If you wait long enough, does the VIN eventually return something sane?

We tried rebooting the comma device while the car was on multiple times and had the same results. Each time we waited for about 30 seconds before the next attempt.

The delay I introduced was 10 seconds and got the 00000000000000000 VIN result. I can try adding a 20-second delay with the below code in car_helpers.py and report back:

def get_car(logcan, sendcan):
  #candidate, fingerprints, vin, car_fw, source, exact_match = fingerprint(logcan, sendcan)

  community_feature_toggle = Params().get_bool("CommunityFeaturesToggle")

  if community_feature_toggle:
    cloudlog.warning("no matching fingerprints, retrying: : %r", fingerprints)
    time.sleep(20)
    candidate, fingerprints, vin, car_fw, source, exact_match = fingerprint(logcan, sendcan)

  if candidate is None:
    cloudlog.warning("car doesn't match any fingerprints: %r", fingerprints)
    candidate = "mock"

  CarInterface, CarController, CarState = interfaces[candidate]
  car_params = CarInterface.get_params(candidate, fingerprints, car_fw)
  car_params.carVin = vin
  car_params.carFw = car_fw
  car_params.fingerprintSource = source
  car_params.fuzzyFingerprint = not exact_match

  return CarInterface(car_params, CarController, CarState), car_params

[pd0wm]

This is a car sold in the US? The VIN is requested using the very standard OBD-II PID, so no complicated UDS stuff going on here.

[sunnyhaibin]

This is a car sold in the US? The VIN is requested using the very standard OBD-II PID, so no complicated UDS stuff going on here.

This car is sold in Canada. If it’s using OBD-II PID, what would be the next step?

[pd0wm]

Can you ensure the rlogs are uploaded for the route with all zero VIN? That's the default value we put in case of an exception.

Can you read the VIN using something like an elm dongle?

I also don't think this is related to your CAN error you see later when openpilot is running. That probably just means an address check is failing in carstate.

[sunnyhaibin]

@pd0wm Oddly enough, no VIN from an ELM dongle as well:

I'll double check in carstate and make sure the signals are good. Will report back.

[sunnyhaibin]

@pd0wm Upon initial comparisons between cabana and carstate, I couldn't identify the root cause of the potential failed address check. I didn't see any logs in tmux associated to it as well.

How can I check and grab logs for failed address checks?

[adeebshihadeh]

Should be fixed with #24311

[sshane]

Doesn't seem fully fixed, at least for non-US market vehicles, this is a Australian 2022 Kona EV: 1d6ecb67ec23a1b8, vin is all zeros

[sunnyhaibin]

Corresponding to Shane's update: #23517