Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Tesla Wall Connector load sharing protocol

This site may earn commission on affiliate links.
You certainly don't give up easily, I give you that ! Great research.
If you go on like that, there will be nothing left for me by the time my Tesla 'hardware' finally arrives. :rolleyes:

I guess your next logical 'attack vector' is the 14-pin JTAG connector (CNA8).
Tesla rangers have tools & software to access it - see this old post: Model S - HPWC (High Power Wall Connector)

@widodh : as a senior / seasoned member of the Dutch TMC-community, could you possibly get access to a Maxem user in order to sniff the messages it exchanges ?
 
You certainly don't give up easily, I give you that ! Great research.
If you go on like that, there will be nothing left for me by the time my Tesla 'hardware' finally arrives. :rolleyes:

I guess your next logical 'attack vector' is the 14-pin JTAG connector (CNA8).
Tesla rangers have tools & software to access it - see this old post: Model S - HPWC (High Power Wall Connector)

@widodh : as a senior / seasoned member of the Dutch TMC-community, could you possibly get access to a Maxem user in order to sniff the messages it exchanges ?
That would be a idea indeed! Just sniff Maxem and ser what they send. I do not know which hardware would be the easiest to use though.
 
Ah, yes. Just sniff all the packets. Easy as that! Didn’t think of that. Now I need to find somebody with Maxem

They also need to own a Protocol 2 TWC. If they bought the TWC in 2018 or maybe late 2017 it should be Protocol 2. Then you need to somehow direct Maxem to stop charging and see if it's possible. If the TWC red light starts flashing then they're stopping charging by stopping communication with the TWC, which works but randomly causes the car to refuse to charge again until you re-plug it.
 
I guess your next logical 'attack vector' is the 14-pin JTAG connector (CNA8).
Tesla rangers have tools & software to access it - see this old post: Model S - HPWC (High Power Wall Connector)

I considered the JTAG but since that's a completely proprietary system, I highly doubt I could figure out how to do anything with it. Even if I got the basics and started sending random commands I'm more likely to break it further than I am to fix it. I think it was irresponsible (or a bug) to let RS485 commands reset or otherwise break a TWC. JTAG, on the other hand, is meant for factory testing and technician use so I would not expect there to be guards in place to stop you from doing something that can cause damage. If I have indeed entered some sort of factory programming mode, that shouldn't have been possible with RS-485 - they should have used JTAG.

I think burning a working NVRAM image would be faster, easier, and more likely to work. Not that doing so is necessarily easy.
 
They also need to own a Protocol 2 TWC. If they bought the TWC in 2018 or maybe late 2017 it should be Protocol 2. Then you need to somehow direct Maxem to stop charging and see if it's possible. If the TWC red light starts flashing then they're stopping charging by stopping communication with the TWC, which works but randomly causes the car to refuse to charge again until you re-plug it.
I will ask around and see if I can find somebody
 
Just to confirm: there are only 2 bits used for the address space of the wall connectors in a master-slave configuration ?
So normally it will not be possible to dynamically control more than 3 or 4 chargers with 1 controller ?
Thinking about a config with 8 chargers where we want to optimize charging based upon power output of our own solar PV.
 
Just to confirm: there are only 2 bits used for the address space of the wall connectors in a master-slave configuration ?
So normally it will not be possible to dynamically control more than 3 or 4 chargers with 1 controller ?
Thinking about a config with 8 chargers where we want to optimize charging based upon power output of our own solar PV.

Each TWC has a two BYTE id ranging from 1 to 0xFFFF. Although the manual says only 4 TWCs can be linked together, there's nothing about the protocol that implies such a limit. I've never tried simulating 4 or more TWCs on a network so I'm not sure what would happen. I suspect normally the master TWC would show an error light when it detects more than 3 other unique ids, but if TWCManager is playing master, maybe there would be no limit? Slaves could also detect the presence of more than 3 other TWCs and show an error but I'm not sure if they do or not. You could give it a try. TWCManager will currently show an error when more than 3 slave TWCs are connected and it will drop the oldest slave from its memory. You would have to modify that behavior in sub new_slave.

The 9600bps speed of communication limits it to ~70 messages between TWCs per second, but Master is expected to send a heartbeat message per second to each Slave, and Slave sends one heartbeat message back. Voltage and amps are exchanged periodically, which adds up to 2 more messages during some seconds, so up to 4 messages per second per TWC pair. 70 / 4 = 17 max TWCs in theory but I suspect with processing time and perhaps intended delays designed between messages the actual limit is lower.

Even if slaves start showing error lights when they detect more than 3 other slaves on the network, you could use two Rapsberry Pi Zeros running two copies of TWCManager and separate your TWCs into two groups of four. You'd have to modify TWCManager to talk to the other master TWC wirelessly when deciding how to split power between the two groups. If the wifi link was ever lost you would need a safe fallback state. Perhaps choose one TWCManager that shuts down its charging or set them both to draw exactly half the available power.

Also note that TWCManager sends one heartbeat message per ~1.1 seconds to each slave in a round robin. That works fine for small numbers of TWCs but with 8 there would be over 8 seconds of delay between heartbeats for each slave. That could help you fit more slaves on the network but it might also cause slaves to think Master has disappeared. I seem to remember slaves wait 20 seconds before they decide that, but it's something to watch out for. I assume a real TWC master would send a heartbeat to every slave once per second but I've never monitored to confirm that. Allowing 8 seconds of delay between heartbeats is probably not safe if you ever tell one TWC to rise to max amps and wait 8 seconds to tell another TWC to go to min amps, so I would advise altering TWCManager to send heartbeats more often with more than 3 real TWCs being controlled.

Also, a real TWC Master uses a tactic of sending state 06 or 07 to gradually shift each slave up or down by 2 amps every 10 or 20 seconds which makes things even more safe as far as preventing one slave from spiking power up when another slave is still using high power. TWCManager is not that advanced and will use state 09 to set an absolute amp limit on all TWCs whenever a new car plugs in or a car unplugs. I think that's probably fine with up to 3 TWCs such that they each get the new settings within 3.3 seconds, but it might be an issue with 8 TWCs and 8.8 seconds of delay. Basically, TWCManager was not designed with the idea of controlling more than 3 real TWCs in mind.
 
Last edited:
Thanks for the explanation @CDragon
By the way: at a ‘Pioneer’ event about 2 months ago Tesla told us in their presentation they were doing a pilot with Cohere/Maxem on smart charging / load balancing. So they seem to be be involved more officially now.
Just still surprises me Tesla hasn’t come up with some sort of more intelligent solution for this, after all it’s mostly software. Obviously not very high on the priority list in CA.
 
I suspect the firmware and settings are stored in the TMS320F28034 (the big square IC on the board) . I did identify the 14 pin JTAG connector (CNA8).
Pinout is:
1 - TMS (pin60 IC)
3 - TDI (pin 59)
5 - 3v3
7 - TDO (pin 58)
9,11 - TCK (pin 57)
13 ---| 5K |--- 3v3

2 ---| 2k2 |--- GND
4,6,8,10,12 - GND
14 ---| 5K |--- 3v3

I did get a C2000 piccolo launchpad evaluation board to play a bit with the architecture, but haven't had time yet to use it yet.
 
  • Informative
Reactions: M_VdM
Straight from the horse's mouth (TI):

JTAG.jpg
 
People keep suggesting JTAG, but according to this, posted in 2013:

Various microcontroller, have a specific bit, that when it set, the JTAG connectors are disabled. This is done on release, to make sure that no one tries to steal the firmware or to debug the system. The only way to enable the JTAG again is to hard reset the microcontroller. This will cause complete reset of the internal flash, so all the firmware will be lost...
I would just like to add that in my experience (high-end devices) more often than not hard resetting doesn't work for enabling the JTAG. These interfaces are often permanently locked by blowing a fuse. In the other cases they're password protected by 64-bit keys with significant delays (milliseconds up to a second) between possible unlock attempts. Just to make sure you don't even want to think about brute-forcing them with a farm of devices. And to fool you a bit they also sometimes like to give you 1 unlock attempt and then silently ignore the reset until a cold reset.

Given all that, it seems really unlikely that Delta (maker of the boards in the TWC) left the chip containing the firmware unlocked. Unless, since TWC is designed to have upgradable firmware, maybe it's more likely to be unlocked?

From the spec sheet for the TMS320F28034 chip, it includes:
128-Bit Security Key and Lock
– Protects Secure Memory Blocks
– Prevents Firmware Reverse Engineering

Even if, by some miracle, the chip is unlocked, accessing it without breaking something requires very careful use of JTAG commands and complete understanding of what you're doing:

You have to be confident that you got things right, because otherwise you can fry your hardware instead of, for example, debricking it.
...
Usually the hardware vendors will claim that they support the McCraigor Wiggler or some other hideously expensive JTAG probe. What this means is that you are on your own if you don't use an "unsupported" (by the vendor) JTAG probe! It doesn't mean it won't work, but it means you have to be damn sure about what you are doing (voltage, JTAG commands you send and such).

Given all that, I consider JTAG to be a tool of last resort. One mistake and things may be unfixable. I wouldn't want to try to use OpenOCD on a Raspberry Pi because the pi is not designed to send signals at a reliable rate. Pi sends signals via "bit banging" which means software tells each GPIO pin when to send a high or low signal, but in the multi-tasking OS the Pi runs, periodic processes can delay things and cause your signal to be sent for too long a period, which means JTAG will get the wrong signal, and that could spell disaster. I'd want to buy a dedicated, high quality JTAG board.
 
Did you have a look at the contents of the adjacent ST 95M01WT EEPROM (UA23) ?
Cfr. @CDragon 's post over here on the EEVblog.​

UA23 is the EEPROM FuzzyLogic said he dumped awhile ago. Sadly, it doesn't seem to contain anything interesting. It's 128k almost entirely filled with bytes set to FF. The only non-FF bytes are:

00 00 01 A7 00 00 00 A1 00 00 00 03 00 00 01 51 00 00 00 00 00 00 01 61 00 00 00 00 5A 00
00 00 01 A7 00 00 00 A1 00 00 00 03 00 00 01 51 00 00 00 00 00 00 01 61 00 00 00 00 5A 00
20 00 11 B2 33 B2 47 65 22 58 06 41 35 00 06 30 43 23


It's possible some of those bytes contain useful settings but they definitely don't correspond to writable data I've found in the RS485 protocol. For example, The FB19 command returns data like:

FD 19 41 31 36 47 30 30 30 31 38 31 34 // "A16G0001814" in ascii, TWC 1
FD 19 41 31 37 49 30 30 33 39 33 39 33 // "A17I0039393" in ascii, TWC 2

These values look meaningful, perhaps a date of manufacture in the first 3 bytes. And you can change these values using the FC19 command, implying they are stored in writable memory somewhere. Since they aren't stored in that EEPROM, they are probably stored in writable memory on the TMS320F28034 chip and it's not likely we can read/write them there. I suppose it's possible they left the section of the TMS320F28034 containing settings unlocked so we could read/write them. So it may be worth investigating the JTAG protocol necessary to read/write to the TMS320F28034 and see if anything is unlocked.
 
  • Informative
Reactions: M_VdM
turns out to be this puppy: Spectrum Digital 's XDS100V2 USB JTAG Emulator !
Texas Instruments' (TI) wiki on XDS100 ...

Good find! I assumed the board was a custom job made by Tesla because of the wire soldered onto it. Such wires tend to be used to correct mistakes in prototype boards. Now that I look at the wire more closely, it looks like it may connect to a power supply component on the board, so maybe it's there to power the board without USB being connected? Maybe it can hang in the TWC on its own and do logging?

Anyway, I did already order a Bus Pirate and a Shikra to probe at the TWC's JTAG. OpenOCD is supposed to be able to probe the JTAG bus for IDs of all reachable components, and with the ID of the TMS320F2803x I hope I will be able to find its "config file" that tells OpenOCD what functions it supports. If all that works out, I can try to read or write to the chip but whether or not that requires a security key is unknown.

Of course, I now see that XDS100V2 supports cJTAG (a newer protocol using only 2 pins instead of 4-5) that the boards I ordered might not support... *sigh*

I also ordered a Pomona 5250 clip to read the EEPROM without desoldering it though I don't expect my EEPROM's contents will be any more interesting than Fuzzylogic's.
 
Last edited:
  • Like
Reactions: M_VdM