Reverse engineering BMS Firmware / Reflashing BMS

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Joined
Oct 17, 2024
Messages
221
Location
Australia
Hey!

I'm looking for a couple of cheap BMS's to extract the firmware and set up an open source tool to reflash them, hopefully via the canbus but worst case via the Jtag/swd/whatever renesas calls their programming port on the PCB. Non working is fine as long as there's is life from the can bus.

We know three things:

  1. Vivne claims to be able to reflash the BCM
  2. Nissan can push firmware updates to it over the CAN bus
  3. The datasheet says there is no read-protect function of the Flash ROM in the MCU.
Ghidra, Renesas's CS+ tool and IDA pro can be used to dissasemble the firmware which should speed up the reverse engineering, and knowing the main CAN commands will quickly help identify where the GID's and pack capacity is stored. This *should* be a fairly simple and quick project.

The only problem is there are no BMS's avaialble on eBay, wreckers won't split the packs open to sell a BMS and I only have the one BMS here and I'd rather not brick mine just yet.

As for my background, I've done a fair bit of reverse engineering, mostly ECU's and game consoles including a full reverse engineer and re-write of Bosch ME7 code to convert it into an open source dirt cheap stand alone ECU (https://github.com/WillItBoost/M744-Stand-Alone-ECU).

If anyone has a cheap BMS or would like to donate one to the cause, let me know!

Ben
 
I wish I could give you mine!

Recently I bought an upgrade kit from VIVNE, for an e-nv200, and one of their premises in order to get their warranty is that they'll send you a reprogrammed BMS but you have to send them yours back.

Guess that may be for two reason:

- Once they got yours back, they can reprogram it and use it with another upgrade kit.
- Not leaving any BMS free at the market xD so anyone can do what they do.

Maybe once I get mine disasembled I can do some tests for you?
 
Hey!

I'm looking for a couple of cheap BMS's to extract the firmware and set up an open source tool to reflash them, hopefully via the canbus but worst case via the Jtag/swd/whatever renesas calls their programming port on the PCB. Non working is fine as long as there's is life from the can bus.

We know three things:

  1. Vivne claims to be able to reflash the BCM
  2. Nissan can push firmware updates to it over the CAN bus
  3. The datasheet says there is no read-protect function of the Flash ROM in the MCU.
Ghidra, Renesas's CS+ tool and IDA pro can be used to dissasemble the firmware which should speed up the reverse engineering, and knowing the main CAN commands will quickly help identify where the GID's and pack capacity is stored. This *should* be a fairly simple and quick project.

The only problem is there are no BMS's avaialble on eBay, wreckers won't split the packs open to sell a BMS and I only have the one BMS here and I'd rather not brick mine just yet.

As for my background, I've done a fair bit of reverse engineering, mostly ECU's and game consoles including a full reverse engineer and re-write of Bosch ME7 code to convert it into an open source dirt cheap stand alone ECU (https://github.com/WillItBoost/M744-Stand-Alone-ECU).

If anyone has a cheap BMS or would like to donate one to the cause, let me know!

Ben

To avoid re-inventing the wheel, have you looked at all the work @Dala has done in the past? Not saying he’s reverse engineered the BMS itself, but he has done a huge amount of investigation and produced the original (I think?) CANBridge. Check out his YT channel and his GitHub as a start.

Another place to ask for a BMS would be the OpenInverter forum. If you start a post there you may find useful people able to contribute.
 
@CherarD that would be great! if you don't mind popping the cover of and snapping some pics, we'll see where vivne have connected their programmer to the board. Could give some valuable information.

@nlspace thanks for the link, I'll take a closer look

@Ianlighting I'm aware of Dala's work, he states pretty clearly its not suitable for 'brute force' mods which I guess is what my CATL kit is that's arriving next week. I'm more interested in reflashing the BMS over CAN to keep the can loom intact and have the BMS report accurate data, safely. Once the protocol is reversed we could ask leafspy to add the reflash code to their next update.

It looks like all the bugs in the canbridge have been ironed out in the last year or so, so that's a great solution. It would be much easier, quicker and cheaper to be able to reflash the BMS in my opinion.
 
I'm in :) let me know how to help on this:

I've a leaf 40kWh 2018 BMS, a broken 24kWh BMS (seems only the can comunication part is broken). I would prefer to remain with them to be used later.
Seems that most of the parameters are saved into an eeprom where lookup tables are saved. The problem is to reverse engineer this memory and understand where the values are mapped.

I can help dumping eeprom and eventually firmware.
There is a russian telegram channel not intended to share memory mapping and way to configure in any case useful to infer some info: https://t.me/ev_battery_flash.

@Ianlighting it is years looking for this info in every place! I suspect that some of this is available in some japan forum that I'm not able to search.
@safetyuggs let me know how I can help. I've basic practice in dumping memories or firmware, but I have friends that can help me. I'll share more detailed photos of these boards if you need detail of the used chips.
 
Last edited:
Ghidra can open the BMS .bin files. The software runs on an "AESC Universal BMS"

.bin file for 30kWh LBC and AESC description: LINK REMOVED

Note that this is NOT considered clean room reverse engineering, and Nissan can sue you for it.

1729776912023.png
 
Last edited:
@ginetto That would be great if you can dump the eeprom! Ideally I'd need two 24kwh eeprom dumps to identify the checksum location and a 30kwh or other dump to see where the capacity info is stored. If it's all stored in the eeprom it would be a few seconds with a soic-8 clip to rewrite it. Once the checksum is generated I can start messing around with the other values to see how the canbus transmissions change.

@Dala this is a huge help! I'll have a poke around in ghidra and see if I can find the EERPOM read/write canbus frames.

Great work everyone! This is looking easier than I thought!
 
I just had a quick look in that binary, there are a LOT of lookup tables in the second half of the ROM. Perhaps voltage vs SOC under various conditions?

If we can get pics from @CherarD to see if they've cleaned off the conformal coating on just the eeprom and not the flash programming pads that will give a good indication that it's only the EEPROM that needs to be modified and not a flash re-write.
 
OK, so there is one main EEPROM read function, it is more or less:

Read_EEPROM_main(EEPROM address, destination address in ram, length);

The last half dozen reads are probably of most interest, being only 2 bytes each. Possible Checksums / capacity / ID's etc...

The first dozen reads are large blocks of data. They are also duplicated so there is likely redundency there in whatever data is being stored.

I'll work backwards from here to find any can functions that read from these memory addresses. We might get lucky and find a can command that'll dump the eeprom contents without having to open the BMS/battery.
 

Attachments

  • EEPROM_Read_Function.PNG
    EEPROM_Read_Function.PNG
    75.1 KB
A whole bunch of the variables are constants defined in the Flash, not the EEPROM. This includes Total pack capacity (here it is hard coded to 0x7407 = 29.7kw)

This means a reflash is needed to change these numbers. Good news is that we found them!

Next up is to find the Flash write CAN commands, if they're even there (I suspect they are but it might just be EEPROM writing)
 

Attachments

  • MaxCapacity.PNG
    MaxCapacity.PNG
    23.2 KB
I can't identify any Flash erase/write functions or any ties to the can RX function to anything other than ordinary TX/RX can data.

This means the BMS must be opened to reflash it. The parameters are easy enough to find and change, there appears to be checksums in the flash but they aren't checked in the code, at least not that I can find a reference to. The Flash protocol is documented and could be done with a $4 stm32 bluepill or duino.

It's interesting the BMS listens to a whole bunch of EVcan messages but doesn't use the data, it just sets and clears flags. Probably as a keep alive check or similar.

So I guess that is as far as I can go until I can source a BMS to read/modify/write and test the reported capacity. I'll keep an eye out for one and update the thread if I can source one.
 
great advance, about can bus there is already a good set of ID documented in Dala's repo here:
https://github.com/dalathegreat/leaf_can_bus_messages
About the editor reader as writer you can use that used by Dala Kvaser "Database Editor 3" that is freeware on win (I run it with wine on linux and it works) or SaavyCan but less intuitive than the first one.Iou can browse in the CAN id and see the internal structure of the message.
 
thx @ginetto, I've got Dala's DBC files for Kvaser but they only list the regular output frames from the BMS, not the query commands. I've used the info in Dala's DBC to track down various CAN functions in the firmware. They were a huge help!

I've just pulled the trigger on a V850 emulator to dump my firmware and see if I can reflash for the 63kwh CATL mod. You can flash the MCU with an arduino but it seems the emulation protocol isn't documented so the only way to pull the firmware out is with Renesas's hardware.
 
thx @ginetto, I've got Dala's DBC files for Kvaser but they only list the regular output frames from the BMS, not the query commands. I've used the info in Dala's DBC to track down various CAN functions in the firmware. They were a huge help!

I've just pulled the trigger on a V850 emulator to dump my firmware and see if I can reflash for the 63kwh CATL mod. You can flash the MCU with an arduino but it seems the emulation protocol isn't documented so the only way to pull the firmware out is with Renesas's hardware.
query commands probably you can get info from the code of battery-emulator in the secion related to leaf batteries:
https://github.com/dalathegreat/Bat.../Software/src/battery/NISSAN-LEAF-BATTERY.cpp
if is this what are you looking for.
 
I just had a quick look in that binary, there are a LOT of lookup tables in the second half of the ROM. Perhaps voltage vs SOC under various conditions?
Can you make these tables as csv for us to look at ? Curious about whether these are how a battery model has been implemented.
 
@safetyuggs
It is possible to update the BMS while it is inside the battery, but I have no capture of a software update unfortunately. Most likely it sets the BMS into an update mode (via the 0x79B-0x7BB request/reply), and then transfers the software bit by bit. Doing it via the Consult 3 is a quite slow procedure, compared to a direct board flash.

If we had a CAN capture from an update, we would really speed this up!

The active polling, is explained in the same Github repository, scroll down and find the document here: https://github.com/dalathegreat/lea...=readme-ov-file#what-about-active-can-polling
 
@MikeinPA I haven't put them in a csv or anything, there are ECU tools that'll search through a binary and show you graphical interpretations of the data. What I'm seeing in the binary (And there's a lot of it) is incrementing values - kind of like 1,2,3,4,5,6,7,8, 1,2,3,4,5,6,7,8, 1,2,3,4,5,6,7,8 but with real data and not 1-8. This is typically what you see in an ECU tune with the various maps or tables.

@Dala any chance you have access to a consult3? that would be super helpful!

Here's the 0x79B parsing function:

```
void Can_RX_79B(void)

{
uint uVar1;
uint uVar2;

uVar1 = DAT_03fec05e & 0x1f;
do {
*(undefined2 *)(*(int *)(uVar1 * 4 + 0x103b4) + 0xe) = 4;
if (*(ushort *)(*(int *)(uVar1 * 4 + 0x103b4) + 0xc) >> 2 == 0x79b) {
DAT_03ffe514 = *(byte *)(*(int *)(uVar1 * 4 + 0x103b4) + 8);
DAT_03ffe508 = 0x79b;
for (uVar2 = 0; uVar2 < DAT_03ffe514; uVar2 = uVar2 + 1 & 0xffff) {
(&DAT_03ffe50c)[uVar2] = *(undefined *)(uVar2 + *(int *)(uVar1 * 4 + 0x103b4));
}
DAT_03ffe515 = 1;
if (DAT_03ffe318 != 0) {
FUN_00045850(&DAT_03ffe50c,DAT_03ffe514);
}
}
} while ((*(ushort *)(*(int *)(uVar1 * 4 + 0x103b4) + 0xe) & 0x2004) != 0);
return;
}


```
As you suggest it appears to copy data from the can packet to a memory address, possibly allowing bootstrapping of some flash code? The function it calls when the last packet has been received will process the data depending if the command sent was either 0x00, 0x10, 0x20 or 0x30. Neither of these commands will branch to the buffer area so there must be other functions responsible for that. The 79B function itself has no references in the code so it's not exactly clear what triggers the function. It does stay in the do/while loop indefinitely or at least until the last packet has been recevied and parsed.

It's a little complicated reflashing this MCU in system as once you erase the flash the code cannot execute. This is likely why there is no direct call to this function, it would need to be copied first to RAM and executed from there, and once you send that erase command you really need to stick with it until completion or you'll have a bricked BMS.

The MCU datasheet says it can swap banks and execute from a different region in flash while it erases the lower banks. I think we really need consult3 update can traffic to see how this is done safely.
 
Back
Top