Tesla: Fix DAS_steeringControlType on newer firmware

[AmyJeanes]

On newer Tesla vehicle firmware across the fleet, we are seeing the DAS_steeringControlType field expanded from 2 bits to 3 bits in the dbc. It is in the same position, the field simply expands by 1 bit into previously unknown/unmapped bits which we can assume were not in use before.

This change first appeared in FSD v14 builds, as the expansion of the field was to allow a new value 4 = FSD to be set as the previous field could only go up to 3, but after some time this change found it's way to normal vehicle builds from update 2026.8.6 onwards and thus is no longer a FSD v14 specific change as was previously noted in the code here.

The resulting behaviour of openpilot when assuming a 2-bit field when it was actually 3-bit resulted in the following behaviour:

• Engaging openpilot would result in LANE_KEEP_ASSIST steering instead of ANGLE_CONTROL steering as 0b01 would be sent by openpilot but read by the car as 0b010
• Vehicle LKAS ("Lane Departure Avoidance") events would result in the FSD v14 suspect being triggered, resulting in openpilot forcefully disengaging and locking out the user with invalidLkasSetting until the device went off-road.
• In the case of sunnypilot with it's Coop Steering setting, enabling that would also result in complete loss of steering as 0b10 would be sent, which was read by the car as 0b100 aka FSD steering which apparently does not work

The changes in this PR essentially allow us to swap between the two different behaviours, the new one with the 3-bit field and the "legacy" one with the 2-bit field, determined using a fixed LEGACY_DAS_STEERING_FW list, similar to the previous FSD_14_FW list but with the behaviour inverted, as it seems Tesla will now be using 3-bit going forwards in all updates to all cars. All firmwares that were previously classified as FSD v14 have been removed from the legacy list to maintain behaviour with the existing code, and additionally some others that have been since confirmed to be using 3-bit.

The test around comparing the firmware list against the suspected FSD v14 rule has been simplified to just ensuring that all entries within the list are also present in the FW_VERSIONS list so they don't get orphaned, but the logic is too complex to accurately add heuristics too and given we can expect all new firmwares from Tesla to include the 3-bit field now that it is in the standard release tracks and no longer exclusive to FSD v14 this shouldn't be an issue going forwards.

The previous FSD v14 handling has been stripped out as part of this PR as it runs on incorrect assumptions that the values themselves had changed, but it was actually the bit size of the field that had changed. Without that knowledge, it appeared as if ANGLE_CONTROL (0b01) had become 0b10 and LANE_KEEP_ASSIST (0b10) had become 0b01 when in fact they had become 0b100 (new FSD value) and 0b010, the same value as before just shifted. Autosteer on these vehicles also went seemingly missing with 0b01 becoming 0b00 but it had actually just moved to the new bit 0b001.

A sunnypilot variant of these changes was installed and tested on several vehicles using both 2-bit and 3-bit firmwares and in one case testing directly before and after upgrading and the new code correctly both read and set the correct values according to several validation routes shared privately with myself.

A new firmware string was also added, a minor variation of an already existing one. Routes are also provided for this below just to be complete.

Routes:

• Old firmware stock AP: 4b3cbd6038d07ca6/00000209--31be0354df
• Old firmware openpilot engaged: 4b3cbd6038d07ca6/0000020a--0029635bdb
• New firmware openpilot engaged / LKAS pass through (courtesy of Tinker2A) : c0fe59cc1ebbd1b3/00000014--3db99b3a52
• Newly added firmware string stock AP: 8ce570e8e64f5bd9/00000016--220a42a198
• Newly added firmware string openpilot engaged: 8ce570e8e64f5bd9/0000000a--0edd90c9cb

[github-actions]

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.

Testing 20 segments for: TESLA_MODEL_3, TESLA_MODEL_Y

⚠️ 2 changed, 18 passed, 0 errors

Show changes

TESLA_MODEL_Y - 2c912ca5de3b1ee9/000002ca--b6db903149/16

  invalidLkasSetting (47 diffs)

  frames 0-52
  master:   _/‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
  PR:       ________________________________________________/‾‾‾‾
            rise: PR lags by 47 frames (470ms)

  stockLkas (5999 diffs)

  frames 0-5999
  master:   ____________________________________________________________________...
  PR:       _/‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾...

TESLA_MODEL_Y - d88fe5d919f6ec47/00000004--641726945a/3

  invalidLkasSetting (1 diffs)

  frames 0-7
  master:   __/‾‾‾‾‾
  PR:       ___/‾‾‾‾
            rise: PR lags by 1 frames (10ms)

  stockLkas (5998 diffs)

  frames 0-5999
  master:   ____________________________________________________________________...
  PR:       __/‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾...

[AmyJeanes]

@sshane this is now ready for review, I've added routes from my own vehicle on the older firmware and a route showing everything working from a car on the newer 3-bit firmware. Please let me know if you need any other routes or anything.

[sshane]

Just one DBC, and set values in reference to the new 3 bit signal? Or use a generator so we don't duplicate message definitions

[AmyJeanes]

Will look into!

[AmyJeanes]

Generator seemed more effort than it was worth given the couple usages just needing a simple bit shift so decided to do that instead but let me know what you think.

Please note I haven't yet tested this in vehicle as my car is in the shop, but I've asked others if they could help test this, and I will test it as soon as I can and let you know.