EU Supercharger visibility enabled on a US Tesla by changing the CAN charge-port type

[Tesla234987234sdf]

Title: EU Supercharger visibility on a US Tesla — implemented in custom firmware
I have implemented a working CAN injection feature in my Tesla Commander firmware that enables German Supercharger locations to appear in the navigation system of my US-market Tesla.
Charging already worked before this modification. The change concerns the charge-port type reported to the vehicle and its effect on Supercharger visibility and route planning.
The relevant CAN message in my setup is:

• Bus: Vehicle CAN (can1 in my firmware).
• CAN ID: 0x25D, originating from the Charge Port ECU.
• Format: Standard 11-bit CAN data frame with an 8-byte payload.
• Field: Byte 0, bits 1:0.
• Modification: Change the US charge-port type from 0 to EU / IEC CCS type 3.
  modified[0] = (original[0] & 0xFC) | 0x03;
  Example:
  Original: 25D#3441010004F0D403
  Injected: 25D#3741010004F0D403
  All other payload bits remain unchanged. Each received US-type 0x25D frame triggers a modified copy, subject to the firmware’s transmission safety checks. No periodic replay of an old payload is used.
  0x25F is left untouched. The unrelated six-byte 0x25D message on Party CAN is also left untouched.
  The feature is already integrated and working in the firmware. I have also implemented improvements to CAN reception, processing and diagnostics:
• Dedicated CAN reception and processing tasks, with immediate handling of the CP correction.
• Deferred logging and diagnostic output to reduce interference with CAN processing.
• Hardware prefiltering combined with an exact software whitelist of the IDs needed by the integrated functions, including configurable signal IDs.
• Automatic restoration of accept-all reception during full CAN logging.
• Diagnostics for receive-buffer overflows, queue losses, CP transmission failures and processing delays.
• Timestamped logs with a manual marker button for correlating observed behaviour with CAN traffic.
  German Superchargers now appear in navigation, and route planning has become noticeably more reliable during my tests. Charging also worked during testing, although I observed intermittent flickering of the Supercharger display.
  The latest CAN filtering changes are built and checked, but their effect still needs vehicle testing. I am not claiming completely loss-free reception yet.
  Because this is parallel injection, the original US-type frames remain on the bus alongside the injected EU-type copies. This may contribute to the remaining occasional routing inconsistencies, but the cause has not been confirmed.
  These results apply to my vehicle and setup; behaviour on other Tesla models or software versions may differ.

[Tesla234987234sdf]

A useful next step would be to move the interface to an externally hosted, offline-capable web app and use BLE for communication with the device, similar to the ESP32-DualCAN project.
The phone would handle the interface, while the ESP32 would exchange commands, status data and firmware updates over BLE. This would allow Wi-Fi and the HTTP/WebSocket services to remain disabled during normal operation, potentially reducing resource usage and interference with time-critical CAN processing.
Wi-Fi could remain available on demand for full CAN logging and maintenance. BLE would not automatically solve CAN reception issues, so any improvement would need to be measured. iPhone compatibility would also need a suitable solution, as standard iOS browsers do not directly support Web Bluetooth.

[nobless]

About BLE integration:
regarding BLE implementation, there is another fork which has fully working BLE solution implemented with extra features that comes with BLE, WIFI is disabled here from the begging as i saw. But application for the phone is not published:

main...ukinora:flipper-tesla-fsd:main

About core task separation i already mentioned in:
#219

there is already implementation for this here:
f806276

[hypery11]

Nice work, and it checks out. The Model 3 DBC has 0x25D on the Vehicle bus as CP_status, 8 bytes, with CP_type in bits 0-1 of byte 0 (0 = US Tesla, 3 = IEC CCS), and the Palladium S/X signal list carries the same CP_type enum. There's no counter or checksum in that frame, so the rewrite is clean. A 2024 Fremont Y dump from #211 has byte 0 = 0x34 too, same as your example.

The flicker is what you suspected. The charge port ECU keeps sending type 0 and your copy follows it, so anything that takes the latest value sees EU nearly all the time, but every missed original or failed TX leaves a full cycle of US. Short of sitting inline on that bus it can't go away completely, your RX task work just makes the misses rarer.

I'd like to bring this in as an opt-in feature: read the car's own type first (works in Listen-Only), then the rewrite, sent back on the bus it arrived on. For the write half I'd put a plug guard back in, like your earlier patch had (no rewrite with a cable connected), until there's a capture showing what charging looks like with it on. From the rest of the zip I'd take the TX and MARK lines in the log, the MCP2515 overflow count and the non-blocking stream write. The 0x7FF and power-limit parts I'd look at on their own, they're not described here. And I'll keep the password on OTA/restart, your copy drops it.

Two things would help. When the Superchargers showed up, were EU Region and Supercharger Access switched off, so is the CP type alone enough? And a short capture around a flicker with can1 25D, can1TX 25D and can0 25F in it, with a MARK when you see it.

On BLE: Web Bluetooth doesn't exist in iOS Safari, so that route needs a native app. Moving web and CAN onto separate tasks gets most of the timing benefit without it.

One heads-up, the build logs in the zip have your Windows user name and paths in them, in case you'd rather re-upload without.

[Tesla234987234sdf]

Today I tested the latest firmware with the hardware CAN filter and some bug fixes, and everything worked reliably.
Route planning completed without any failures, and Superchargers were consistently included in the routes. The display also remained completely stable while charging at a Supercharger, with no flickering.
The feature is now successfully implemented, including the CAN filter for reliable operation without dropped frames or buffer overflows. All previously existing features continue to work flawlessly.
The BLE integration is also complete, fully functional, and working flawlessly. All previously existing features continue to work perfectly as well.
If its possible to get in contact with you?

[Tesla234987234sdf]

I also figure out some more options. All already tested. pls let me know how i can contact you.

[Tesla234987234sdf]

Im done also so many tweaks and mods about the can traffic handle. For now i reached nearly zero can drops all the way. Thats pretty fine. Before the handling has thousands of can drops.

[nobless]

The CP type change is in v2.17-beta.1, thanks for finding it and for testing it on your car. It's in your name in the release notes and the README.

It isn't quite your build, so a few differences matter for testing. The dashboard always shows the charge-port type the car reports, in every mode. The rewrite is a toggle, off by default. When it's on, each US-type CP_status gets a copy with IEC CCS on the bus it came from, through the normal transmit gate. It also has the plug guard: no copy while the frame says a cable is present, the latch is engaged, the door is open, or the cable state is unknown. You saw no trouble charging without a guard, but that's one car, so for now it stays.

Two things I'd like to know from your car. With the toggle on and unplugged, does the status line under the switch say → IEC CCS, or does it say held — plug state unknown? If it's the second, the guard never lets it run on your car, and I need to know that first. Second, our copy is sent from the same loop that serves the dashboard. Do the Superchargers stay put while you have the dashboard open and reload it a few times? Your build moved CAN to its own task, which mine doesn't do yet.

from my car:
BUILD: v2.17-beta.1

also having many errors on TWAI driver (not related with this feature):

[hypery11]

@nobless thanks, that's the first confirmation that the rewrite runs from our build: → IEC CCS (64 sent) with the switch on, and the plain read-out with it off.

The RX missed number is the TWAI receive queue overflowing. It holds 64 frames, which at 2,300 frames/s is about 28 ms, so any pause in the loop longer than that loses frames. You're right that moving reception off the loop is the real fix. f806276 is an April side branch written for the old single-bus loop, so I won't take it as it is. I want to find what stalls the loop first. One I know of from the code is sending the dashboard page, which holds the loop for a few hundred ms per page load. The per-bus numbers coming for #253 will also show which controller is losing frames.

[hypery11]

@Tesla234987234sdf sorry for the slow answer on this. Could you share your Telegram handle? I'll message you there.