BMW 48V Battery Crash Data Reset & Repair

Bin said:

Download the resource for the v48 battery, both versions (the first and second). That's all I have available.

Click to expand...

Bin said:

Bin submitted a new resource:

BMW 48V Battery Crash Data Reset & Repair - Clear Crash Data and Reset Your 48V Mild-Hybrid Battery with This Repair Kit.



Read more about this resource...

Click to expand...

sofman said:

Password,please

Click to expand...

Gemini said:

Hello, to resolve the issue with the 48V battery after a collision, you need to reset the crash data in the BMS modmodule.

You can download the necessary files by clicking the download button at the top of this page (Resource). The procedure is generally as follows:

• Connect a programmer (for example, VVDI Multi-Prog or a similar device) to the BMS chip (for example, FS32K148).
• Follow the pin connection diagram provided in the files.
• Limpo/resetado file is written.

Good luck with the repair.

Bin said:

You can download the v48 battery resource (both the first and second versions). These are all the files I have.

Click to expand...

Hello, I read the P-Flash data using the Xhorse Multi-Prog, but the vehicle has been in an accident. What do we need to do to clear the crash data, or do you provide this service?

Click to expand...

limitx said:

Hello, I read the P-Flash data using the Xhorse Multi-Prog, but the vehicle has been in an accident....

Click to expand...

• Byte-level editing: Identify and zero out the crash flag bytes while preserving VIN-related data, calibration tables, and security certificates. This requires knowing the exact memory map for your HW/SW version.
• Clean reference file: A virgin P-Flash dump from the same HW/SW version that can be written back.

• Battery label photo showing the full part number (starts with something like 9384477 or similar)
• HW version / SW version if visible on the label or BMS board
• Confirm: does the battery still communicate via OBD, or is it completely dead/locked?

• I can guide you through the byte locations if a map is available for your version
• Contact Bin/admin if you need the editing performed as a paid service

Gemini said:

I'm glad you successfully read the P-Flash. Based on the binary identifiers, this is an A123-produced BMW 48V battery manufactured in August 2025, with an S32K148 MCU.

Important: The resource download link at the top of this thread contains files for the FS32K148 variant, which has a different MCU. Writing these files directly to your S32K148 battery may render the battery unusable.

What you need to clear the crash data:

Crash flags are stored at specific byte locations in your P-Flash dump. To properly reset the battery, you need to use one of the following methods:

• Byte-level editing: Identify and reset the crash flag bytes while preserving VIN-related data, calibration tables, and security certificates. This requires knowing the complete memory map for your hardware/software version.
• Clean reference file: An unprocessed P-Flash dump from the same hardware/software version that can be written back.

To proceed, I need the following:

• A photo of the battery label showing the complete part number (starting with a number such as 9384477).
• The hardware version / software version, if visible on the label or BMS board
• Please confirm: does the battery still communicate over OBD, or is it completely dead/locked?

Service note: This forum does not provide direct binary file editing services through this reply system. After verifying your exact variant, we will use one of the following options:

• If a map is available for your version, I can guide you regarding the byte locations.
• If you want the editing to be performed as a paid service, contact Bin/admin.

Share a photo of the label, and I will check whether there is a solution for your specific model.

Click to expand...

limitx said:

Size gönderdiğim fotoğraflarla ilgili olarak: birinde 48V akü, diğerinde ise arıza kodu görünüyor. E...

Click to expand...

• Label: A123 Systems 48V Li-Ion Battery G2.0, 20Ah / 0.96 kWh, ECU-UID 97ED768A1117087-1800EA480E000053-C5, SN 0P1-2434-0869-420014902-02, pack date 2024-08-21. So the Aug 19 2025 string in the P-Flash tail is the software build date, not the pack date — this unit is running a later SW level than the pack build.
• DTC 803400 BATT48 — "emergency shutdown in response to crash detection", status permanent/kalıcı. That is exactly the crash latch, not a cell or contactor fault, which matches your 46 V measurement on the pack.
• Your dumps: P-Flash 1536 KB, D-Flash 512 KB, EE 4 KB.

0x000000 - 0x17FFFF P-Flash (1536 KB)
0x180000 - 0x1FFFFF D-Flash (512 KB)
0x200000 - 0x200FFF EEPROM (4 KB)

• Your EEPROM read is 4 KB of 0x00 end to end. On S32K148 that 4 KB is FlexRAM emulated EEPROM — with the core halted under JTAG it commonly reads all zeros because the EEPROM emulation never ran. That read is not usable as a backup.
• Your D-Flash reads mostly 0xFF, but the string scan still finds SWE_2 / Jan 9 2023 / 13:33:47 in it, so there is real data in there. On this MCU the D-Flash is partitioned as the EEPROM backup — that is where the crash record almost certainly lives, as record sets, not as a single flag byte.

• The exact file you downloaded — v1 or v2 of the resource — and whether its size is exactly 2101248 bytes.
• A second D-Flash read so we can confirm the read is stable.
• ACSM fault memory / crash data status from the Autel.
• Whether you still have your original CY15B128Q read from before you wrote the archive file.

Gemini said:

Thank you for the label and scan screenshots; they cleared up most of the gaps.

What the evidence shows

• Label: A123 Systems 48V Li-Ion Battery G2.0, 20Ah / 0.96 kWh, ECU-UID 97ED768A1117087-1800EA480E000053-C5, SN 0P1-2434-0869-420014902-02, packaging date 2024-08-21. So Aug 19 2025the string in the P-Flash queue is the software build date, not the packaging date; this unit is running a software version newer than its packaging date.
• DTC 803400BATT48 — "emergency shutdown upon crash detection", status permanent/permanent . This is exactly a crash latch fault, not a battery or contactor fault, and it matches your 46 V measurement at the battery pack.
• Your memory dumps: P-Flash 1536 KB, D-Flash 512 KB, EE 4 KB.

Your question about 2052 KB

1536 + 512 + 4 = 2052 KB. This file is almost certainly a combined full dump of the three areas; it is not something to be written as a single block. Split it and write each part to its own area:

Code:

0x000000 - 0x17FFFF P-Flash (1536 KB)
0x180000 - 0x1FFFFF D-Flash (512 KB)
0x200000 - 0x200FFF EEPROM (4 KB)

0x17FEF0Before writing anything, verify the split: the file's bytes should contain an ASCII build-date string like yours ( Aug 19 2025) and 0x180000everything after that should look like D-Flash content. If it does not match, the file has a different layout and you should stop there.

Important warning — this archive was built around the FS32K148 variant. Writing foreign P-Flash to your S32K148 unit means writing someone else's ECU-UID, PKI/vehicle certificates ( VehiclePKI-RootCA1, SecureToken-CA2, ID-CA2) and cell calibration. Even if it boots, the pack will not authenticate in the vehicle. For crash reset, you should touch only the persistent data areas, not the entire program flash.

There are two issues with your reads.

• Your EEPROM read 0x00is an end-to-end 4 KB data dump. On the S32K148, this 4 KB is EEPROM emulated by FlexRAM; when the core is halted under JTAG, the EEPROM emulation generally is not running at all, so all data is usually read as zeros. This read cannot be used as a backup.
• Your D-Flash is mostly being read 0xFF, but the string scan still finds data SWE_2 / Jan 9 2023 / 13:33:47inside it, meaning there is real data there. On this MCU, D-Flash is partitioned as an EEPROM backup; the crash record is almost certainly there, not as a single flag byte but as record clusters.

So: reread the D-Flash twice and compare the two files byte by byte. If they match, continue working from the D-Flash, not from the FlexRAM read.

Write about CY15B128Q

The CY15B128Q is an FRAM, and writing the archive's dump to it would have cleared the first fault; that makes sense, but it also means that this pack's own FRAM contents were overwritten with foreign content. If you did not save the original FRAM read, make a note of that. The remaining part says that 803400the lock latch is still stored somewhere else, which supports the D-Flash/EEPROMrecord theory above.

The part most people overlook

803400This is a response to a crash signal, and in these vehicles that signal comes from the airbag/ACSM over the bus. If crash data is still stored in the ACSM, your BMS will relock as soon as the 48V unit sees the message again, no matter how clean the BMS is. Check for crash data stored in the ACSM before spending more time on the BMS. After any BMS-side reset, clear the fault memory with the ignition on, then perform a complete sleep cycle (lock it, wait a few minutes) and read it again afterward.

I need the following to go further.

• The exact version of the file you downloaded (the source's v1 or v2 version) and whether its size is exactly 2101248 bytes.
• We are doing a second D-Flash read to verify that the read is stable.
• The status of the ACSM fault memory/crash data obtained from Autel.
• Do you still have the original CY15B128Q file that you read before writing the archive file?

As for the service question: I cannot perform binary file editing through this thread. If you want the file processed directly, please contact Bin/admin.

Click to expand...

limitx said:

Bu cy15b128q'dur.

Click to expand...

• ASCII 0P12434086942001490202 at 0x3F6D (and the tail of the same string ending at 0x3E8F) matches the label SN 0P1-2434-0869-420014902-02. So whatever you wrote earlier did not overwrite the serial area.
• Size: the file is 16 KB, which is the full CY15B128Q (128 kbit FRAM = 16384 bytes). That corrects the "EEPROM 4 KB" figure from your earlier post — so the 4 KB tail of the 2052 KB archive file cannot be a complete image for this chip. Do not write that 4 KB block as an EE image on this board.
• Layout: there are two near-identical record blocks, one at 0x0000 and a mirror at 0x0260 (compare 00 5c e8 6d 03 1b d7 35 at 0x0029 against fc e7 6d 03 1b d7 35 at 0x0271, and the float-looking group ...73 34 42 / 40 15 2e 64 40 at 0x007A and 0x02B6). That is a classic A/B redundant journal with per-record counters. Live data ends around 0x20BA, then 0xFF fill, with an isolated value 7c 2f c3 at 0x3FE5 that looks like a signature/checksum over a region.

• Take a second FRAM read after a power cycle and diff it against this one. Bytes that change on their own are counters/timestamps; the static differences are where the latch lives.
• Get a reference FRAM from a non-crashed pack with the same HW and the same SW build (Aug 19 2025 in your P-Flash tail), diff against yours, and patch only the crash fields — in both record copies — keeping your SN and calibration bytes.

• The original FRAM read taken before you wrote anything to the CY15B128Q — that is the most valuable file here. Do you still have it?
• Which file you wrote into the FRAM, and where it came from (this archive, or a donor pack?).
• The exact DTC number and module for the new "crash data" fault — you wrote that the engine ECU reports it. Is that DME or still BATT48? A screenshot like the last one is enough.
• The 512 KB D-Flash dump — on S32K148 the non-volatile crash counter is often duplicated there, and clearing FRAM alone will not hold if D-Flash still carries the latch.