The work-in-progress Arduino implementation of a BMS controller is up on Github: https://github.com/collin80/TeslaBMS
Reverse engineer, reprogram or otherwise use the UV/OV/balancing circuits built into each of the 16 modules in a Tesla Model S battery pack.
The work-in-progress Arduino implementation of a BMS controller is up on Github: https://github.com/collin80/TeslaBMS
Example diagram showing wiring of the J1 connectors to the master BMS board.
Adobe Portable Document Format - 78.17 kB - 02/21/2017 at 06:47
Adobe Portable Document Format - 332.76 kB - 02/21/2017 at 06:20
py - 4.37 kB - 02/20/2017 at 04:57
Diassembled with DASMx
lst - 179.14 kB - 04/18/2016 at 00:37
Raw 8k flash dump from the uC using the C2 debug interface. Viewable in a hex editor.
hex - 8.00 kB - 04/18/2016 at 00:37
One of the reasons I wanted to reverse engineer rather than replace the microcontroller on the module BMS board is that Tesla have carefully selected voltage levels for under/over voltage thresholds and balancing levels. So it's a bit of a bummer to find that the modules themselves don't seem to have these values built in, it's handled higher up the control chain.
But the BQ76 does have a hardware over and under voltage threshold, as well as over temperature built in, which pulls a shared fault line low.
There are also some other configuration values worth reading out, and since I do have a bunch of boards which have had power applied since the last time they were used, since they have this huge battery backup - the hundreds of 18650 cells - to keep the RAM powered!
So how do we read it out? need to find the address first, using my python script we can iterate through the possible addresses with something like
for address in range(0x3E): sendData(Read,[address, 0x00, 0x4C])
And eventually, at address=0x0F I get the result:
TX: 0x1e, 0x0, 0x4c,
RX: 0x1e, 0x00, 0x4c, 0x81, 0x2a, 0x25, 0x25, 0xa5, 0x25, 0xab, 0x25, 0xae, 0x25, 0xad, 0x25, 0xac, 0x25, 0xaa, 0x0a, 0x99, 0x0a, 0x93, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3d, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8f, 0x00, 0x00, 0x00, 0x00, 0x10, 0x80, 0x31, 0x81, 0x08, 0x81, 0x66, 0xff, 0x15, 0x00, 0x00, 0x00, 0xad,
Labeling each register:
0: 81 #status register 1: 2a 25 #GPAI measurement data 3: 25 a5 #cell 1 voltage data 5: 25 ab #cell 2 voltage data 7: 25 ae #cell 3 voltage data 9 25 ad #cell 4 voltage data b: 25 ac #cell 5 voltage data d: 25 aa #cell 6 voltage data f: a 99 #TS1 voltage data 11: a 93 #TS2 voltage data 13-1f rsvd 20: 0 #alert status 21: 0 #fault status 22: 0 #OV fault state 23: 0 #UV fault state 24: 0 #parity result A 25: 0 #parity result B 26-2f rsvd 30: 3d #ADC measurement control 31: 3 #I/O pin control 32: 0 #cell balancing control 33: 0 #cell balancing max on time 34: 0 #ADC conversion start 35-39: rsvd 3a: 0 #group 3 registers write access control 3b: 8f #Address register 3c: 0 #reset control 3d: 0 #test mode selection 3e: rsvd 3f: 0 #EPROM programming enable 40: 10 #Function configuration 41: 80 #IO configuration 42: 31 #OV setpoint 43: 81 #OV time delay 44: 8 #UV setpoint 45: 81 #UV time delay 46: 66 #over temperature set point 47: ff #over temperature time delay 48: 15 #user data 1 49: 0 #user data 2 4a: 0 #user data 3 4b: 0 #user data 4
So the values after 0x3F are identical to those read from the EPROM on a restart, they set to OV/UV/OT and time delays.
OV setpoint = 0x31, datasheet says 2V + 50mV * 49 = 4.45V
UV setpoint = 0x08. datasheet says 0.7V + 100mV * 8 = 1.50V
OT setpoint = 0x66. Table 2 says this corresponds to 1.578V, which is 65C for a 10k NTC such as ERT-J1VG103FA
Interesting values, the cells will basically be on fire if they reach these voltages.. The temperature value is much more reasonable.
Since we can't guarantee the register content, best practice is to just reset the BQ76 chips with a broadcast reset, then set it up from scratch. EPROM values will be loaded automatically but there are a few registers that require setup after a reset, Address control, ADC control, IO control and the fault and alert registers.
### ~~ Startup Code ~~ ### #A5 is the magic value to reset the chips sendData( Write, [broadcast, RESET_CONTROL, 0xA5]) #set address sendData( Write, [0x00, ADDRESS_CONTROL, address|0x80]) #do this for each BMS on the daisychain #configure ADC sendData( Write, [address, ADC_CONTROL, 0x3D]) #configure IO sendData( Write, [address, IO_CONRTOL, 0x03]) #clear faults, need to write a 1 to the fault bit to be cleared, then a zero sendData( Write, [address, ALERT_STATUS, 0x80]) sendData( Write, [address, ALERT_STATUS, 0x00]) sendData( Write, [address, FAULT_STATUS, 0x08]...Read more »
As I found in the last post, the isolated UART bus daisychained through the Tesla modules is running at an odd frequency, 612,500bps. This is problematic as it is not a standard PC baud rate. I had an FTDI board lying around so I had a peek at the datasheet to discover it has a highly configurable baud rate generator, easily configured to within 3% of 612kbps. In addition, the windows driver handles configuration automatically.
To test this out I wrote a python script, PySerial was fine with the non standard rate, and the frequency was confirmed with a logic analyser.
One of my collaborators, Tom has been probing out a module BMS hooked up to a master board, he found that a serial string is periodically transmitted and this results in SPI bus activity, just the status register being read. However, we had issues decoding the exact UART messages as he was lacking decent analysis tools. I Figured I would try repeating the test by sending the supposed data with my FTDI board anyway.
All I observed was each byte being repeated on the other side of the daisychain bus as expected from analysing the UART ISR code. I started modifying the bytes and noticed any string starting with 0x00 or 0x01 was repeated with that first byte modified to 0x80 or 0x81. At first I thought it was a read error but it was consistant and verified with a logic analyser.. Still no activity on the SPI bus.
Then a coding mistake led me to send long strings of 0x000000 etc. running the logic analyser I saw the SPI bus come alive!
The UART responded with an additional 0x00. The SPI bus had repeated the 0x000000 message and added/read out a 0x00, It's like the microcontroller is acting as a UART/SPI bridge, with something funny happening on the first byte.
Working on this theory, I constructed a valid SPI read message according to the datasheet: http://www.ti.com/lit/ds/symlink/bq76pl536a-q1.pdf
Lets try 0x00 00 01 - This should read 1 byte from device 0, address 0
And I got a reply! 0x61. 0x35 is the CRC8 of 0x00000135 This was the same reply recorded by Tom with his master/module BMS pair. strangely a very different uart command to what he seemed to record so there may be more to this. But it does seem like the microcontroller provides (almost) direct SPI access.
Taking it to the extreme, lets read out all the registers by sending 0x00 0x00 0x4C as there are 76=0x4C total register bytes
RX: 0x80, 0x00, 0x4C, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x80, 0x31, 0x81, 0x08, 0x81, 0x66, 0xff, 0x15, 0x00, 0x00, 0x00, 0x7F
Side note, looks like there is EEPROM data being loaded in for the UV/OV points and timers too. Translates to overvolt threshold of 4.45V and undervolt threshold of 1.5V, which seems very low to me.. I'm guessing the master BMS handles much of the protection by polling the cells. The GPAI ADC channel is also pointed to VBAT, so this channel is by default going to be measuring the voltage of all 6 cells in the module.
So taking a closer look at the first byte as this clearly differs from the SPI protocol and contains some undocumented magic. It's my best guess that bit 7 is used as a blocking bit to allow address assignment to each module. The middle 6 are the device address as per datasheet. So the last bit must be the R/W bit. (which is why both 0x00 and 0x01 have the bit7 blocking bit set when they are repeated)
I confirmed this by writing to the address register, then reading it back using the new address:
TX: 0x01, 0x3b, 0x81, 0x8b,
RX: 0x81, 0x3b, 0x81, 0x8b,
TX: 0x02, 0x3b, 0x01,
RX: 0x02, 0x3b, 0x01, 0x81, 0xba,
We write 0x81 to the address control register (0x3B), (where bit7 here indicates...Read more »
Here is a rough schematic of the isolated bus circuitry.
It looks like there is some shared "open collector" style bus on CH4 of the isolator, with D8 and (I assume) a pullup on the BMS controller board. But so far I've only ever measured this line being low, thus disabling the entire bus. I haven't worked out what U5 is yet. probably a dual logic gate. Maybe it combines error signals out of the BMS IC..
Ch1 is used to bring the BMS out of low power mode. A low frequency oscillator powers up U4 periodically checking on the state of CH1. The whole thing then stays powered while CH1 is driven low (otherwise CH1 is high impedance if the bus side of the isolator is unpowered, the circuitry must detect this and shut down) I can't really be bothered tracing out much more of the circuit. the layer of varnish on everything and tracks disappearing into internal layers makes it a nightmare.
Ch2 and 3 look like the main comms lines, connected to the UART of the uC. J1 is set up such that Tx of one channel is connected to Rx of the next, so they daisy chain together. The first BMS in the chain must get a "go" command from a controller board.. so I just have to work out how to say "go" as discussed in my last post.
I thought I'd just check that Tesla had the security bit set to protect the firmware from reading.. already had a SiLabs JTAG/C2 programmer so I wired up the 2-wire C2 interface.
And turns out.. The firmware is totally readable! Tesla wanted to make my life a bit easier. Thanks Tesla! There is about 5KB of used codespace. I ran it through an 8051 disassembler, DASMx. The SiLabs C51 uC's are totally 8051 compatible, meaning binary operands and memory locations are the same, so DASMx can even decode the SFR addresses into memonics for me. Its supposed to be able to 'flatten' out the code, using all the calls and branches to make it more linear to read but it would only process 3% of the code when I tried that option.
Here is the hex: https://cdn.hackaday.io/files/10098432032832/code.hex
And disassembled code: https://cdn.hackaday.io/files/10098432032832/code.lst
And the chip datasheet: https://www.silabs.com/Support Documents/TechnicalDocs/C8051F52x-F53x.pdf
There are a few thousand lines of assembly. I started by looking at the interrupts, as some of the code is most likely interrupt driven, especially the UART RX.
Code at 0x12A9: mov iec,#0B0H, this writes to the interrupt enable Special Function Register, enabling interrupts on Timer2 and UART0. The UART interrupt vector is 0x0023, which contains ljmp L0C0F, which does another ljmp L0DB9 which contains the code below!
0DB9 L0DB9: 0DB9 : C0 E0 " " push acc 0DBB : C0 F0 " " push b 0DBD : C0 83 " " push dph 0DBF : C0 82 " " push dpl 0DC1 : C0 D0 " " push psw 0DC3 : 75 D0 00 "u " mov psw,#000H 0DC6 : C0 00 " " push X0000 0DC8 : C0 01 " " push X0001 0DCA : C0 02 " " push X0002 0DCC : C0 03 " " push X0003 0DCE : C0 04 " " push X0004 0DD0 : C0 05 " " push X0005 0DD2 : C0 06 " " push X0006 0DD4 : C0 07 " " push X0007 0DD6 : 30 99 05 "0 " jnb ti,L0DDE 0DD9 : 75 2B 00 "u+ " mov X002B,#000H 0DDC : C2 99 " " clr ti 0DDE L0DDE: 0DDE : 30 98 30 "0 0" jnb ri,L0E11 0DE1 : 85 99 2A " *" mov X002A,sbuf 0DE4 : E5 2C " ," mov a,X002C 0DE6 : 60 21 "`!" jz L0E09 0DE8 : E5 2B " +" mov a,X002B 0DEA : 60 05 "` " jz L0DF1 0DEC L0DEC: 0DEC : 30 99 FD "0 " jnb ti,L0DEC 0DEF : C2 99 " " clr ti 0DF1 L0DF1: 0DF1 : E5 2D " -" mov a,X002D 0DF3 : 60 0D "` " jz L0E02 0DF5 : E5 2A " *" mov a,X002A 0DF7 : 54 FE "T " anl a,#0FEH 0DF9 : 70 07 "p " jnz L0E02 0DFB : E5 2A " *" mov a,X002A 0DFD : 44 80 "D " orl a,#080H 0DFF : FF " "...Read more »
Did some probing of the BMS and tracing out of the isolated circuitry, I think I have figured out how the basic communication bus SHOULD work..
Looks like Tesla have powered down the uC and isolator chips to save energy when the car is turned off, they do this with a switch between the IC Vss/gnd and the TI BMS IC's Vss/gnd, looks like U5 and U5 are the switches. U2 appears to be a voltage regulator (judging by the heat it produces when powered on.)
They have an oscillator which enables the isolator IC periodically, if the bus side of the isolator is powered, pin 14 will be pulled low, this then enables the uC and isolator until the isolated bus is unpowered and pin 14 goes high impedance. When it poweres up, the uC flashes the onboard LED, but it doesn't send out any data, in fact it pulls the data line low..
Pin 17 of the uC is connected to an output channel of the isolator, pin 16 is connected to an input, these are UART TX/RX pins so it's a safe bet that some serial protocol is used to enable the board and read out data. and it's not just a simple
Unfortunately it's going to take a long time to brute force the serial baudrate and combination of bytes which makes data flow.. so this is a dead end unless I can get my hands on a working Tesla with it's pack ripped open to probe the bus.. Anyone?
Otherwise plan B is to write my own code to run on the Silabs uC and interface with the BMS IC.