Tesla Model 3 Battery Hacking

[Jack Bauer]

How to tell a good bms from a bad, Lesson 1: A good bms draws f%^k all current from its attached battery when in sleep mode:)

[Jack Bauer]

So time for a little bms update. Now that we have our bench battery and slave setup we can connect the whole lot to a hv controller. Looking at the pt can output on message 0x332 we see the cell voltages correctly reported. Then we can spy on the spi with the salea and actually see the data coming in from the slave board. But what we can now do most importantly is to cause changes in that data by messing with the connected cells.

[tom91]

Can you export raw hex data of the SPI bus? Then I would not mind having a look at it, I would suspect quite some likeness to the standard linear chip protocol.

[Jack Bauer]

Attached capture from Salae logic analyser. Can be viewed with free software : https://www.saleae.com/downloads/

Few points to note : The spi runs with Cpol=1 and Cpha=1. The capture starts with the hv controller powered down and powers on after about 0.5sec. One slave connected with all 25 cells attached.

[Jack Bauer]

Ignore my last. I am a clown. Attached capture as before but with correct spi decode pin assignments.

[Jack Bauer]

So a few observations from looking at the logic analyser data.

1)Looks like all transactions ar 16bit
2)Seems the controller spits out 0x2ad4 to wake the salves from sleep and get them to respond.
3)Slave responde with : 0x0fff
4)Master sends : 0x4e53 , 0x2500
5)Slave then sends an 18 byte response.

I have 2 hv controllers. One (mine) I have cut the tracks from Batman (Elon equivalent to the LTC6820) to the stupid NXP micro. This allows us to send isospi with our own device (arduino due) using the Tesla spec that the slaves will recognise. On the 2nd hv controller I can spy on the spi with the salae and watch the results over can to correlate what changes on the spi when I mess with the cell voltages and how that corresponds to the real life data sent out over can. Yeah, another Tour De Force:)

[tom91]

What voltage are your cells at?

The protocol does not look like "standard ISO SPI" for any of the Linear Chips i have reviewed.

[tom91]

So it turns out some way this works seems like:
2nd from last byte is echoed before the slave data.

It seems the the byte before it indicates some form of register or something.

Since there are two connected IC's We are are seeing the first IC and then IC2 send the same info, always 9 bytes per IC for a full response, the rest if buffered with 0xFF due to no other IC's/slaves present.

Seeing that I am seeing alot of values of around 0x9FCD - 0xA033 ish and then usually reported in sets of 3 (which is the way the LTC6813 usually reponds).

[tom91]

I get a wierd feeling Tesla is doing something along the lines of what the old chips used to do for comms.

Model S and other variants used this chip from TI with SPI translated on to canbus.
https://www.ti.com/lit/ds/symlink/bq76p ... BQ76PL536A

But then not using the fields as defined here but different and getting all ICs to respond in a burst. I have seen 3 byte commands and 4 byte commands in the capture.

[Jack Bauer]

Oh i bet it won't be straightforward. Cells are at about 3.25v each and reported temp was 19c at time of capture. I'll be installing some pots on the pack to allow varying the voltage of a few cells.

[tom91]

Oh i bet it won't be straightforward. Cells are at about 3.25v each and reported temp was 19c at time of capture. I'll be installing some pots on the pack to allow varying the voltage of a few cells.

If you vary a few voltages and send another capture I can figure it out.

[Jack Bauer]

Total of 6 captures now up on the repo with log detailing the events and pictures of received can data on 0x332 just after the log.
https://github.com/damienmaguire/Tesla- ... man_1Slave

[Jack Bauer]

Musk Vs Arduino.

Tried sending 0x2ad4 to the slave via spi on a due. Of course it didnt do anything. Seems the due will break the transaction into bytes whereas Elon uses words. Might be time for an stm32 here unless anyone knows better?

[tom91]

Musk Vs Arduino.

Tried sending 0x2ad4 to the slave via spi on a due. Of course it didnt do anything. Seems the due will break the transaction into bytes whereas Elon uses words. Might be time for an stm32 here unless anyone knows better?

How are you sending it? How about sending it as 0x2A and then 0xD4?

[Jack Bauer]

Tried that. Every option I have tried with arduino breaks spi transactions into bytes. Even this results in two bytes:
receive1 = SPI.transfer16(send1); // do a transfer

[Jack Bauer]

Well there's your problem Lady!
From arduino spi.h

inline static uint16_t transfer16(uint16_t data) {
union { uint16_t val; struct { uint8_t lsb; uint8_t msb; }; } in, out;
in.val = data;

[Jack Bauer]

We got a reply!

Did a bit more digging into the spi library. Seems the Teeny can actually do 16 bit transfers. Dug about and found a 3.1. Uploaded this sketch and bingo! we get a reply of 0x3fff when we send 0x2ad4 just like on the captures:)

Code: Select all

// inslude the SPI library:
#include <SPI.h>
#define SS 10
uint16_t send1=0x2ad4;
uint16_t send2=0x0000;
uint16_t receive1=0;
uint16_t receive2=0;
byte count1=8;

void setup() {
  // put your setup code here, to run once:
SPI.begin();
pinMode(SS,OUTPUT); //select pin
SerialUSB.begin(115200);//normal port
}

void loop() {
  if (count1>0)
  {
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));//1mhz clock,msb first, mode 3
digitalWrite (SS, LOW);        // assert Slave Select
receive1 = SPI.transfer16(send1);  // do a transfer
receive2 = SPI.transfer16(send2);  // do a transfer
if(receive2!=65535) SerialUSB.println(receive2,HEX);
digitalWrite (SS, HIGH);       // de-assert Slave Select
SPI.endTransaction ();         // transaction over
delayMicroseconds(20);
count1--;
  }
if (count1==0)
{
count1=8;
delay(75);
//SerialUSB.println(receive1);
  
}
  
}

[mdrobnak]

Nice progress!

[tom91]

Oh i bet it won't be straightforward. Cells are at about 3.25v each and reported temp was 19c at time of capture. I'll be installing some pots on the pack to allow varying the voltage of a few cells.

Uhmm really Damien, why make things hard?

Capture two data analysed

so you can see quite well that numbers for some reason line up very very well.

I will try documenting some more, specially the requests as i notice they vary slightly.

[tom91]

Okay so my findings are:

Need a few captures of "dry starts" So first time powering on 12V to see if any initialisation takes place.

So the format for request is:

Byte 1: Requested Register
Byte 2: Counter (same as response leading byte of each slave)
Byte 3: Checksum (Needs confirmation)

I am working on breaking down the registers, got all the voltage registers Identified also got an incline to where the temperatures are hiding.

[Jack Bauer]

Nice work Tom:) I'll put up a few more captures tomorrow. Yeah, I guess the hard part was getting past Tesla's silly version of the isospi. Once I get transmit sorted on the fpga we should be close to a controller when combined with simpbms.

[Jack Bauer]

Tom, does simpbms bring out the spi pins?

[Jack Bauer]

One capture now up with a full cold start of hv controller with one slave connected :
https://github.com/damienmaguire/Tesla- ... man_1Slave

[tom91]

Tom, does simpbms bring out the spi pins?

Nope, once we got something I will come up with a bodge to make it work.

[tom91]

So currently looks like the requests are structured as follows:

Code: Select all

Request	Len	Info
 0x47	9	Cells 1, 2, 3
 0x48	9	Cells 4, 5, 6
 0x49	9	Cells 7, 8, 9
 0x4A	9	Cells 10, 11, 12
 0x4B	9	Cells 13, 14, 15
 0x4C	7	?
 0x4D	9	Temps?
 0x4E	9	?
 0x4F	7	?
 0x50	7	?

Damien, mind requesting out of the blue some of these after sending the wake up? Just to see how the slave responds.

Example would be:

Code: Select all

Request	 0x47	 0x00	 0x70

Attached my analysis spreadsheet, found another command that has no repsonse so migh be an init.

Code: Select all

Request	 0x2B	 0xFB