DimonLipko
Member
Cool! Maybe faster way flash new SW in chip via external programmer.
I think that need read leaf BMS from 30kWh battery and compare with 24kWh.
I think that need read leaf BMS from 30kWh battery and compare with 24kWh.
Reverse engineering BMS Firmware / Reflashing BMS
- Thread starter safetyuggs
- Start date
Help Support My Nissan Leaf Forum:
liuguoqing351
Member
- Joined
- Mar 8, 2020
- Messages
- 11
30=40(*´I`*)
Probably not a good idea to share or distribute any of Nissans code.
I'll share my modified firmwares when they're ready as patches to apply over genuinely sourced firmwares, the same way patches for ROM hacks have been distributed the last few decades.
I'll share my modified firmwares when they're ready as patches to apply over genuinely sourced firmwares, the same way patches for ROM hacks have been distributed the last few decades.
20seconds to flash via JTAG, 5min with a consult3, 30min with a $4 can-usb adapter.
Flashing over obd2 is much more convenient, especially if you need to update more than once.
New topic about the values we are pretending to modify,
I think Nissan must have implemented some software compensation in the BMS for the resistance of the different busbar lengths.
When manufacturing a pack with a different module layout, sometimes the busbar lengths do not match the original Nissan ones and that creates some increase of the voltage delta under hard accelerations.
It would be nice to know if it would be possible to adjust also that resistance to make perfect upgrades in the future.
What does the community think about it?
DimonLipko
Member
I make custom battery based on leaf OEM bms, and i change wire lengths from cell to bms and it worked fine.
LKA
Active member
an increase in voltage delta during hard acceleration is usually caused by poor contact between busbar and battery module
nismoboy34
Member
- Joined
- Apr 1, 2022
- Messages
- 12
Ive made more than 10 packs . Sure resistance does have a bearing on how current flows . But the sample rate during a hard pull is generally short lived . The only proviso nissan built in was between cells 48 and 49 there is two extra reference wires on the 24Kwh pack . I wont if its the same for the 40Kwh pack ? Any one with a pin out (these go to the safety disconnect at the top of the pack) and because there is a 32mm2 wire running between the front half of the pack and rear half of the pack it makes sense that this would be where the voltage drop would be seen.
I would say even with a serious move around of cells grouped similarly front 48 and rear 48 we have not seen any issues with Huge delta V . We over spec the busbars by going thicker on the longer runs .
Take for instance the pack on the 24KWh has long bus bars between the modules in the returns as its a long slender pack . But these dont reflect in leaf spy when doing a hard pull .. granted actually the whole pack sags as a whole .
Longer cell taps has been a question for the better part but again these can be compensated by doubling the wire thickness to the longer runs reducing resistance on them and mitigating voltage drop.
I have part no's for the Crimps on the stock connectors if any one wants ( hence why we can make up different harness cables into the stock LBC connectors)
I would say even with a serious move around of cells grouped similarly front 48 and rear 48 we have not seen any issues with Huge delta V . We over spec the busbars by going thicker on the longer runs .
Take for instance the pack on the 24KWh has long bus bars between the modules in the returns as its a long slender pack . But these dont reflect in leaf spy when doing a hard pull .. granted actually the whole pack sags as a whole .
Longer cell taps has been a question for the better part but again these can be compensated by doubling the wire thickness to the longer runs reducing resistance on them and mitigating voltage drop.
I have part no's for the Crimps on the stock connectors if any one wants ( hence why we can make up different harness cables into the stock LBC connectors)
ginetto
Well-known member
some balancer (at least I saw during balancing) do the resistance and calibration calculation. I suppose that this BMS take into account this. The BMS knowa the energy entering and the voltage changes, so could estimate IR of the cell+busbar. Or at least I hope it would be able to estimate it! @safetyuggs did you find any part of the code where there some IR estimation, would be some related with Hx calculation.
I haven't looked at that part of the code yet but it should be fairly easy to spot any special treatment to cells separated with longer cable lengths.
Measuring entire pack sag under load would be an easier way to measure pack HX rather than per cell.
Interesting theory though
Measuring entire pack sag under load would be an easier way to measure pack HX rather than per cell.
Interesting theory though
Added a new can function to dump the ROM at a requested address.
Bootrom dump in ~90 seconds
If you have experience in Assembly language, and have a bench'd BMS to develop firmware on, please PM me.
The latest set of BMS Tools!
KWP2BIN will convert your KWP into a Binary, ready for ghidra or patching.
Run fixchecksums.bat on the patched binary when you're done
BIN2KWP will convert it back to a KWP
leafBMSflash will write the KWP to the BMS
If you're using an AZE0 firmware, substitute 3E002_checksum.exe with the AZE0 version in the batch file.
the bin2kwp is fully compatible with my flash app, probably not compatible with Consult but untested.
This should be everything you need to modify and flash a custom firmware.
As long as you don't wreck the main loop code in the firmware, it should be more or less 'brick proof'. There's a WDT running so if your code crashes, or causes a protection fault it'll restart. As long as it doesn't execute the bad code right away, it'll be recoverable by reflashing.
In the ZE0 firmware, some values that are of interest:
0x240900 = 2,361,600 = 23.616 KWH
0x5C40 = 23,616 = 23kwh
I still need to identify where the Ah value is stored.
there are two other checks in the firmware, if > 24kwh, it'll fix the capacity to 24kwh. This needs to be an 8byte opcode to expand that to 64kwh, patching over the opcode isnt' possible, you could just nop through the check, but better yet would be a branch to unused code space, do the math there then jump back after the check.
GIDs appear to be derived from the above values, so in theory, changing only those should keep the bms happy with larger cells.
The chemistry tables are still for the original NMC's, and consider a full charge at around 95% SOC, which is probably a good thing for longevity. We're working on finding these and modifying, once we get the core code happy with 63kwh patches
PID21_82 is a great function to modify if you wanted to extract data from your BMS - and could be done on any BMS version as long as you have a compatible firmware (you can buy them from nissan-tech)
KWP2BIN will convert your KWP into a Binary, ready for ghidra or patching.
Run fixchecksums.bat on the patched binary when you're done
BIN2KWP will convert it back to a KWP
leafBMSflash will write the KWP to the BMS
If you're using an AZE0 firmware, substitute 3E002_checksum.exe with the AZE0 version in the batch file.
the bin2kwp is fully compatible with my flash app, probably not compatible with Consult but untested.
This should be everything you need to modify and flash a custom firmware.
As long as you don't wreck the main loop code in the firmware, it should be more or less 'brick proof'. There's a WDT running so if your code crashes, or causes a protection fault it'll restart. As long as it doesn't execute the bad code right away, it'll be recoverable by reflashing.
In the ZE0 firmware, some values that are of interest:
0x240900 = 2,361,600 = 23.616 KWH
0x5C40 = 23,616 = 23kwh
I still need to identify where the Ah value is stored.
there are two other checks in the firmware, if > 24kwh, it'll fix the capacity to 24kwh. This needs to be an 8byte opcode to expand that to 64kwh, patching over the opcode isnt' possible, you could just nop through the check, but better yet would be a branch to unused code space, do the math there then jump back after the check.
GIDs appear to be derived from the above values, so in theory, changing only those should keep the bms happy with larger cells.
The chemistry tables are still for the original NMC's, and consider a full charge at around 95% SOC, which is probably a good thing for longevity. We're working on finding these and modifying, once we get the core code happy with 63kwh patches
PID21_82 is a great function to modify if you wanted to extract data from your BMS - and could be done on any BMS version as long as you have a compatible firmware (you can buy them from nissan-tech)
NocturnalWalt
Active member
- Joined
- Dec 2, 2015
- Messages
- 25
Firstly, to safetyuggs - very impressive progress especially in the short time frame. Well done.
Regarding Hx calculation (or the internal resistance coefficient in Nissan terminology), that's relatively straightforward to understand at a high level, but actually one of the trickier things to correctly calibrate for aftermarket cells. We've looked at this mostly on the 30kWh LBCs, but the earlier LEAF LBCs look quite similar. It's all primarily based on pack voltage drop vs pack current while the car is being driven. The pack current has to be high enough to get some usable data, but once there is enough current the LBC is always feeding this into the calculation.
The LBC uses a 3D lookup table that is calibrated presumably based on empirical test data. One axis is the calculated internal resistance as mentioned above and the other is the average battery temperature. The value from the table is used to feed Hx into a very slowly averaging filter. On the 30kWh at least, it looks like they tested cells in new condition at various temperatures. Then they likely cycled the cells for a long time and re-did the tests again for various temperatures. Finally some interpolation was done to fill in a bunch of unknown data points in the 3D table.
Most importantly, Hx is the primary input into deriving SoH (using another 3D table). The values in this table make it look like they measured the capacity of new and aged cells vs the increase in internal resistance to populate that table. So effectively that table gives the relationship between the expected capacity loss (SoH) and internal resistance (Hx). Nissan themselves got the values in this table quite wrong in the initial 30kWh firmware – hence the need for a revision. What wasn’t obvious at the time was why. In hindsight I suspect it’s because of the difference between ageing based on cycles alone vs cycles and calendar life. With calendar life included the internal resistance increase has been a lot higher than expected compared to the remaining capacity.
When using aftermarket cells, you could just set the SoH table to give 100% SoH in all cases and all will be fine for the first year or two at least… But down the track it will become an issue as SoH is very important in calculating charge bars, GoM, etc.
Regarding Hx calculation (or the internal resistance coefficient in Nissan terminology), that's relatively straightforward to understand at a high level, but actually one of the trickier things to correctly calibrate for aftermarket cells. We've looked at this mostly on the 30kWh LBCs, but the earlier LEAF LBCs look quite similar. It's all primarily based on pack voltage drop vs pack current while the car is being driven. The pack current has to be high enough to get some usable data, but once there is enough current the LBC is always feeding this into the calculation.
The LBC uses a 3D lookup table that is calibrated presumably based on empirical test data. One axis is the calculated internal resistance as mentioned above and the other is the average battery temperature. The value from the table is used to feed Hx into a very slowly averaging filter. On the 30kWh at least, it looks like they tested cells in new condition at various temperatures. Then they likely cycled the cells for a long time and re-did the tests again for various temperatures. Finally some interpolation was done to fill in a bunch of unknown data points in the 3D table.
Most importantly, Hx is the primary input into deriving SoH (using another 3D table). The values in this table make it look like they measured the capacity of new and aged cells vs the increase in internal resistance to populate that table. So effectively that table gives the relationship between the expected capacity loss (SoH) and internal resistance (Hx). Nissan themselves got the values in this table quite wrong in the initial 30kWh firmware – hence the need for a revision. What wasn’t obvious at the time was why. In hindsight I suspect it’s because of the difference between ageing based on cycles alone vs cycles and calendar life. With calendar life included the internal resistance increase has been a lot higher than expected compared to the remaining capacity.
When using aftermarket cells, you could just set the SoH table to give 100% SoH in all cases and all will be fine for the first year or two at least… But down the track it will become an issue as SoH is very important in calculating charge bars, GoM, etc.
DimonLipko
Member
It is amazing!))) Tomorrow, I can start play with azeo bms on the bench.
I have .kwp file with software update for 30kWh bms, and I know that it is possible to reprogram 24kWh to 30kWh with Consult3.
I have .kwp file with software update for 30kWh bms, and I know that it is possible to reprogram 24kWh to 30kWh with Consult3.
Very intersting! Thank you for sharing
This will give me a good place to start looking when the time comes for accurate HX calcs.I don't suppose you have the offsets and structures of these maps?
And would you know which can message Ah is transmitted on? It'll help me track down where it's coming from - the available docs both in the wiki and dala's are not for the ZE0 and the frame structure isn't even close
You can reprogram a AZE0 24kwh with 30kwh firmware, but you can't put 30kwh firmware on the ZE0 BMS - It'll probably flash just fine but there's a good chance it'll brick it - None of the entry points in the code are in the correct place.
DimonLipko
Member
Yes, this true, because zeo have other A
This is logical, that impossible update ZEO bms to 30kWh becouse there different ASIC chip)
That makes sense from what we've found. I know the AZE0 30kWh BMS user data starts at a different code location to the ZE0. While both seem to run on the same kind of chip, from AESC, being a different generation makes sense. The code seems slightly different too, but not entirely.
I suspect that's what the bridge does.
explorer232
Well-known member
- Joined
- Jul 13, 2023
- Messages
- 53
Has 30kWh aze0 bms similar hw as ze1 bms? There is one grey and one black connector in this 30kWh bms like ze1 bms.
If someone have these LBC firmwares for AZE0, we can compare differences (lookup tables....). Last letter can be different.
4NP2A -- 24kWh
4NP4A -- 30kWh
4NP6A -- 40kWh
Last edited:
