Reverse engineering BMS Firmware / Reflashing BMS
- Thread starter safetyuggs
- Start date
Help Support My Nissan Leaf Forum:
Dumping back, the firmware did not change any eeprom data. I wonder if it is not exactly SOH but instead cell Ah capacity and SOH is derived from it. I'll fiddle with the values to see if I can get the Ah to read what my catl cells are supposed to be.
Negative. Anything larger than the GIDs magic value will default to 100% SOH. This check is in the firmware too. Changing pack capacity appears to require a reflash.
The 230JT..... code? I didn't see it anywhere on the PCB but it is a plain text string in the eeprom. or am i looking at the wrong place in LS?From the LS screen:
The 2.1 million Amps was promising
Also the VIN was showing back as an ASCII string from the eeprom dump. Is that the part number printed on the circuit board?
Hx represents battery conductance (inverse of resistance) per LeafSpy, and as such is not a percentage.
It tracks SOH over a battery's life time, decreasing. My data (mohms - inverse of Hx) from my '13 Leaf indicate this:
11/20/14 -13,700 miles, 76 mohms per LeafDD, 20 Deg, 73% SOC, 90% SOH
11/27 -13,800 miles, 67 mohms per LeafDD, 25 deg, 63% SOC
11/30 - 13,900 miles, 56 mohms per LeafDD, 27 deg, 71% SOC
12/2 - 14.100 miles, 55 mohms per LeafDD, 28 deg, 67% SOC
12/16 - 14,500 miles, 89 mohms per LeafDD, 15 deg, 93% SOC
12/27/14 - 14,800 miles, 103 mohms per LeafDD, 11 deg, 24% SOC
3/10 - 17,400 miles, 60 mohms per LeafDD, 30 deg, 73% SOC
3/14 - 17, 550 miles, 56 mohms per LeafDD, 32 deg, 47% SOC, 85% SOH
4/14 - 19,100 miles, 59 mohms per LeafDD, 25 deg. 38% SOC
5/4 - 19,989 miles, 64 mohms per LeafDD, 24 deg. 48% SOC
5/15 - 20,400 miles, 73 mohms per LeafDD, 20 deg. 41% SOC
5/22 - 20,700 miles, 58 mohms per LeafDD, 28 deg. 50% SOC
12/10/15 - 28,000 miles, 90 mohms per LeafDD, 19 deg. 92% SOC
4/5 - 32,000 miles, 74 mohms per LeafDD, 24 deg, 55% SOC
5/16 - 33,700 miles,89 mohms per LeafDD, 22 deg, 47% SOC
5/16 - 33.700 miles, 58 mohms per LeafDD, 31 deg, 76% SOC, 80% SOH
10/5 - 39,300 miles, 100 mohms per LeafDD, 22 deg, 50% SOC
10/6 - 39,400 miles, 61 mohms per LeafDD, 30 deg, 51% SOC
10/7 - 39,500 miles, 80 mohms per LeafDD, 25 deg, 56% SOC
10/15 - 40,000 miles, 71 mohms per LeafDD, 27 deg, 45% SOC
10/30 - 41,000 miles, 74 mohms per LeafDD, 23 deg, 66% SOC
12/26/16 - 43,000 miles, 110 mohms per LeafDD, 13 deg, 77% SOC
6/10/17 - 49,600 miles, 89 mohms per LeafDD, 19 deg, 70% SOC
7/1/17 - 51,000 miles, 62 mohms per LeafDD, 33 deg, 44% SOC
8/15/17 - 53,400 miles, 61 mohms per LeafDD, 35 deg, 57% SOC, 75% SOH
Last edited:
Maybe that is the battery serial number, along the lines of Group 84 found in Dala's guide:
Code:
Group 84
Name: Battery Serial
Type: String
Description: Battery serial number
Query:
0x79B 02 21 84 00 00 00 00 00;length,Pid,Group
0x79B 30 00 00 00 00 00 00 00; request more time
Answer:
0x7BB 10 16 61 84 32 33 30 55;reply,len,P,G,data
0x7BB 21 4B 31 31 39 32 45 30;2nd line reply, data
0x7BB 22 30 31 34 38 32 20 A0; 3rd "
0x7BB 23 00 00 00 00 00 00 00; 4th "
Formula: (323330554b313139324530303134383220A0).decode(’utf-8’)
Last edited:
I have a BMS sitting around that came with a junkyard battery I bought last spring. My leaf is a 2011 and the batter came out of a later model(I think 2013) so I can’t even use it in my car for anything.
I have it torn apart for curiosity sake and have been thinking about doing exactly what is going on in this thread.
PM me if I can be of help.
I have it torn apart for curiosity sake and have been thinking about doing exactly what is going on in this thread.
PM me if I can be of help.
PID27_65 Code. When issuing PID27,command 0x65, the BMS will send you a 4 byte Challenge. You have 10seconds to reply with the correct (Edit: A wait time of 10sec is requried for a new Challenge to stop brute forcing) response.
Here is the function which sends and checks your reply:
The Seed is generated from a 32bit integer which increments every 10mS and is xor'd with memory data.
The decrypt_seed function is as follows:
Once returned true, Flags are set which allows other can commands which will otherwise return an error response. This includes EERPOM writing
I have not yet tested the above code, when the spare BMS's arrive I'll give it a go.
Here is the function which sends and checks your reply:
The Seed is generated from a 32bit integer which increments every 10mS and is xor'd with memory data.
The decrypt_seed function is as follows:
Once returned true, Flags are set which allows other can commands which will otherwise return an error response. This includes EERPOM writing
I have not yet tested the above code, when the spare BMS's arrive I'll give it a go.
Last edited:
Pid31_03_01 will reset SOC/SOH, if CAN_Process_Flag == 0xC0.
To set CAN_Process_Flag to 0xC0: Send PID10_C0
This doesn't appear to require a seed/key response though to preserve to EEPROM it does. I'll test this today
To set CAN_Process_Flag to 0xC0: Send PID10_C0
This doesn't appear to require a seed/key response though to preserve to EEPROM it does. I'll test this today
ginetto
Well-known member
for sure you can help dumping the memory content of the eeprom (probably the same as shown in previous pthotos in the thread).
waiting for you contribution
cheers
If you have a USB-Can bus interface, and a 12v power supply there are a few tests you could run
coulomb
Well-known member
Sorry, I'm again quite late to the party; many things going on at present.
Multiplying by a strange constant and doing a right shift by (word size in bits) is a common strength reduction optimisation used by compilers. In this case, they seem to be dividing by about 5403.82, as 0xC20B2 = 794,802 = 2³² / 5403.82. The problem is that this results in a number less than one, but I note that the decompilation suggests that both this value and the value before it was shifted right by 32 bits are passed to the function. So it's like a 64 bit fixed point number with the binary point in the middle, i.e. one half has the number before the binary point, and the other half has the value after the binary point. It seems a strange way to pass a non-integer number, but it's not totally insane. Some would call this a Q32 number (a fixed point number with 32 bits after the binary point).
[ Edit: Originally I forgot to divide by the nominal capacity. ]
SOH = capacity / nominal_capacity * 100. For a 30 kWh battery, SOH = cap_Wh / 30,000 * 100 = cap_Wh / 300.
So SOH / 5403.8 = cap_wh / 300 / 5403.8 = cap_Wh / 1,621,140. 1,621,140 / 65536 = 24.73, so these would be units of 24.7 kWh. In other words, this could be the capacity relative to a new 24 kWh battery (presuming 69.6 Ah per module when new, or 34.8 Ah per cell).
So this could be a Q16 number, of the capacity compared with a new gen 1 battery. It's a stretch, I'll agree.
And I suspect I'm still wrong; sigh.
Last edited:
That ss from post #60 shows the VIN in the header, whereas when reading just the battery pack we saw a "?? serial number?" in the header that had digits stored on the eeprom. i found another battery pack read with what i think is the serial number in the header,
This was found on the NZ Drive EV site which provides a battery pack reading service.
You can 'read ecu data' in leafspy to show just the BMS serial
Hey all, not a software expert but have 24kwh 2013 car bms (black interior) that i can poke open and do pictures of, down to microscopic level if it helps. Probably take readings of some chips etc too. But if that is already covered then nevermind
PS. don't forget to wipe your phone lenses, helps a lot with picture clarity very often!
PS. don't forget to wipe your phone lenses, helps a lot with picture clarity very often!
