Tesla Model 3 Charge Port Controller Standalone Development

[Jack Bauer]

Wow. I need that key soooo badly:)

[mdrobnak]

Wow. I need that key soooo badly:)

Hehehe apparently those who have them almost never use them.

One minor detail - it's UHF around 433 MHz, not RFID from the handle. As long as the car is unlocked, or you have your phone on you, it'll just open when you hit the button on the (Tesla brand) handles. Or make your own. Bjorn Nyland did I think. If I understand it right, it's just a known short radio burst, similar to remote key fob for things like E46 BMWs, but with the same data all the time.

-Matt

[New Electric Ireland]

Or make your own.

We've already documented that

viewtopic.php?f=17&t=303#p3637

[Jack Bauer]

Ok I know we are going off topic but I just checked and my Tesla wall charger has a button! Wheeeee! Never realised until now:)

[mdrobnak]

Now we're getting somewhere...


No, you can't have full power right away, stop being so greedy.

-Matt

PS Pardon the mess, it's cold downstairs by my workbench, so I dragged some of it upstairs, and I wanted to share some news quickly. I'll probably have a nicer shot for Instagram tomorrow.

[Jack Bauer]

The pulsing blue T of happiness:)

[mdrobnak]

* Init code fixed
* Fixed standby state to be solid blue LED.
* Removal shouldn't trigger red LED now.
* Haven't removed unnecessary IDs yet, I wanted that to be a different commit to keep the changes clean.

Redacted repository updated. Going to go for a walk now.

-Matt

Edit: I'm an Instagram N00000b. I totally meant to edit out the semi-fail at the end..but : shrug :

[JaniK]

Oh nice very cool.

[mdrobnak]

Oh nice very cool.

Thanks.

Damien has the code which was used in the video above, and has sent me some data to look over. I'll be doing that today as I have time.

Punting on the ISA library for the moment, as figuring this out is probably a little more pressing.

-Matt

[mdrobnak]

Super LOL moment.
So my unit when unhappy has a 5 second on, 3 second off pattern. I thought that was the CP ECU resetting itself in a watchdog type thing. Nope! It's my cheap Best Buy power supply giving out.

I now have a real power supply:

and it no longer does weird stuff. It also auto-closes itself after a 2 minute timeout, just like the car.

Tried getting the other older CP ECU to work, but no luck. That's all for tonight.

-Matt

[Jack Bauer]

Yep, very same happened to me. Musk needs amps.

[mdrobnak]

Yep, very same happened to me. Musk needs amps.

Yeah I was like Damien's crazy, this works fine for me. The power brick has a blue LED on it, and it was under the table in my office. So I didn't see when the light would go off...

I moved my test setup upstairs, and can see where the power brick is out of the corner of my eye. When I saw the weird stuff happening, and the light going off, I was like 'Well crap, Damien was right.'

Normally that Agilent / Keysight now is stupid expensive...over $450+, but the local electronics store had it on clearance for $250.

I tried replaying some main-bus IDs on the hV bus to try and coerce the non-working US unit to go, but not sure if SavvyCAN couldn't keep up, or it just didn't like it -- either way no changes. I have the correct connector arriving today so I can make a nicer set for keeping in the car, and for being able to swap between the 3 I have (including the car) more easily.

So today's ToDo:
* Set up two connectors
* Review log data where I interrupt the charging in progress and ensure my behavior is similar

-Matt

[mdrobnak]

I set up the connector yesterday for the bench ECU. I just prepared the car one tonight, which is fun because I have made it so I can use a logic analyzer / multimeter / CAN sniffer on things without having to touch it. This way I can completely put the carpeting back again (for the second time! LOL), but still get measurements when I need to. Car is asking to do another software update, I want to get my sniffer in place while that happens (on both buses this time). Hopefully no more updates to the Charge Port ECU, but who knows.

Also, looks like it gets power hungry only when it's annoyed. Still needs over 1.5 amps for a moment when closing the door after that 2 minute timeout, but not that bad. Was more than the 1.1 amps the old brick could handle.

Tomorrow:
* Get more-permanent setup in car.
* Test sending some IDs from Vehicle Spy this time, maybe it'll be less annoyed.
* Do software update. Log, but just set aside for now.
* Review interrupted charging log.

I will be able to borrow a friend's J1772 charger so I'll double check that works later this week as well.

-Matt

[mdrobnak]

Got the setup in the car. I'll get pictures tomorrow. Much easier to capture both CAN buses at once.
Didn't test IDs from Vehicle Spy yet. I did test two IDs from SavvyCAN, no difference.
Wasn't actually a software update - just a navigation data update. Nothing to report.
Didn't review the log. I think the deal is I just need to implement a delay before declaring charge restart desired.

I did borrow the J1772 charger, and that is (now) working as expected. Turns out 1 != 2. Code updated on github.

-Matt

[mdrobnak]

Tested a bit with Vehicle Spy.

Good news:
* CP ECU in car still works.
Bad news:
* Oldest CP ECU still doesn't work. Made some progress but hit a wall.
Just the facts:
* I have no idea how to determine which data version it wants. Basically a recent update removed one of the Touchscreen UI status IDs, or rather, it moved it. It was a very low ID (0xC) and that didn't make sense for what it was. So they moved it to lower priority. That was easy. They also added a byte to a different UI related item controlling the charging, and the new code doesn't react to the shorter message.

Calling it a day now. I'm going to go relax for the rest of the evening.

-Matt

[mdrobnak]

Oh, look, the old firmware ECU:

Through the power of macros, I was able to do this:

send_empty_frames!(hv_can, 8, [100,101,102...];

which expanded into:
send_empty_message(hv_can,8,100);
send_empty_message(hv_can,8,101);
send_empty_message(hv_can,8,102);

which allowed me to start bisecting the space quickly.

I have 100 IDs to bisect now. I should have this good to go in about 30 minutes.

Also, trying to send 1000 IDs at once on the STM32F4 just overwhelmed the poor thing. The F7 didn't do much better.

-Matt

[mdrobnak]

Bisection complete! I found the pesky ID. 12 rounds.
For those unfamiliar with the term, it means this:
1,2,3,4,5,6,7,8,9,10

Bisect it and test 1,2,3,4,5. If that falis, test 6,7,8,9,10.
If 6,7,8,9,10 works, test 6,7,8. Then 6,7, then 6. Then you found the answer. Basically keep dividing the search space in half.

Totally lucked out that it is a 8 byte Id as that's what I figured was most likely...

-Matt

[collin80]

* I have no idea how to determine which data version it wants. Basically a recent update removed one of the Touchscreen UI status IDs, or rather, it moved it. It was a very low ID (0xC) and that didn't make sense for what it was. So they moved it to lower priority. That was easy. They also added a byte to a different UI related item controlling the charging, and the new code doesn't react to the shorter message.

-Matt

Yeah, Tesla has a bad habit of changing all sorts of things between firmware releases. It makes it tough to figure out what a given device is wanting. I guess that's why Damien has been so busy building retrofit boards. There's a way to know for sure which firmware a charge port is actually running:

0x53E is charge port info. It's multiplexed on byte 0. You can probably use multiplex value 0xD which gives you the application CRC. Then the application CRC32 is the last four bytes (4,5,6,7). From there you can determine which firmware version the CP hardware was loaded with if you somehow had a list of CRC values corresponding to firmware values. I don't, in fact, have such a list. It could be built up by asking people with known firmware versions to send in their 0x53E messages and then record the CRC32 value. Naturally, since people usually update quite quickly this means you'd have to do this going forward and getting the historical CRC values would be more irritating.

Of course, the other part of that is that you'd need to know what each release is really looking for. It seems like quite an undertaking. But, at least knowing whether a CP has a version you know how to work with might be handy? Then you could better determine whether the thing is broken or just wanting different comm.

[mdrobnak]

Yep, I started thinking about that today. Crappy solution. But a workable solution. I have at least 3 values already.

There's still some oddities in behavior in the older firmware...

-Matt

[Jack Bauer]

Nice work Matt:) I have 2 ecus here and another stuck in Irish customs for a few more data points.

[New Electric Ireland]

We have two more EU ECU's that we can use for test. We also have one of the EVTV CAN capture tools in a UK Model 3 if anyone needs log files.

One observation, all three EU ECU's we've purchased have the same part number despite coming from different European countries with a two year age difference. In contrast, the US ECU's we've purchased have different part numbers.

Screenshot 2019-10-12 at 12.24.58.png (108.62 KiB) Viewed 3167 times

[New Electric Ireland]

This might help explain some of the different US ECU part numbers and possibly some parts to avoid - "On some Model 3 vehicles, an electrostatic discharge might damage the charge port ECU radio transceiver. As a result, an alert displays on the touchscreen, and the charge port door is unable to be opened using the button on a charger handle. The charge port door opens using other methods."

https://static.nhtsa.gov/odi/tsbs/2018/ ... 3-9999.pdf

[Jack Bauer]

Finally got rid of the red T. I like blue. Blue is better then red. Also got my paws on another EU ccs ecu and this one comes with a bit of musk loom to make life much easier:)

[New Electric Ireland]

Also got my paws on another EU ccs ecu and this one comes with a bit of musk loom to make life much easier:)

Another P1092755-82-B

[mdrobnak]

This might help explain some of the different US ECU part numbers and possibly some parts to avoid - "On some Model 3 vehicles, an electrostatic discharge might damage the charge port ECU radio transceiver. As a result, an alert displays on the touchscreen, and the charge port door is unable to be opened using the button on a charger handle. The charge port door opens using other methods."

https://static.nhtsa.gov/odi/tsbs/2018/ ... 3-9999.pdf

Interesting. Of note, my initially working model was a -98 (from a 2019), my car is a -99 (Sep 2018 delivery), and the initially non-working model was a -99.

We have two more EU ECU's that we can use for test. We also have one of the EVTV CAN capture tools in a UK Model 3 if anyone needs log files.

One observation, all three EU ECU's we've purchased have the same part number despite coming from different European countries with a two year age difference. In contrast, the US ECU's we've purchased have different part numbers.

I'm assuming some have -98 in the number, and some have -99 in the number. Those are the only two I know of for US ECUs. One of the "US" ECUs that Damien has does have a different number, and does not report itself as a US ECU. It reports itself as a "GB" ECU.

AFAIK there's only one number for EU, being the -82.

-Matt