need repair 48v battery TC277 mercedes

Gringos said:

I need repair file for battery mercedes
after failed 12v battery , 48v does not make output 48v

d...

Click to expand...

Based on the information you've provided, I can see you're dealing with a Mercedes 48V EQ Boost battery (mild hybrid) with a BMS managed by an Infineon TC277 microcontroller.

This is a common issue — after a 12V battery failure or deep discharge, the 48V BMS can lock out and stop providing 48V output. The BMS stores fault flags and sometimes corrupts internal calibration/state-of-health data.

However, I cannot open your RAR file on this server — only metadata was extracted. I need the actual dump to work with.

Before anyone can help with a repair file, please clarify:

• Read method: How was the TC277 read? (Boot mode / BDM / BAM / JTAG via which tool — e.g., PCMFlash, Autotuner, Dimsport, KTag, etc.)
• Read type: Is this a full flash read (internal flash + DFLASH + UCB) or only a partial read?
• File size: What is the exact size of the dump? (TC277 full internal flash is typically ~4MB, but it depends on the read configuration)
• Vehicle: Exact model, engine code, and year (e.g., W205 C200 M264 2019)?
• Symptoms: Any DTCs stored? Does the BMS communicate on CAN at all, or is it completely dead on diagnostics (Xentry/Star)?

Important notes on 48V BMS repair:

• Simply clearing DTCs is usually not enough — the BMS stores persistent fault counters and battery state data in DFLASH that need to be reset.
• If the BMS has gone into a permanent lockout state, specific internal flags need to be identified and corrected.
• A virgin/original file from the same HW/SW revision is ideal for comparison — do you have the SW version (e.g., from Xentry or from the dump header)?

Please re-upload the dump in .zip format (or share via a file hosting link) and provide the details above so the file can actually be analyzed.

hi need repair 48v Mercede GLE53 AMG battery eeprom 5m01 . Tried q files I will uliad.

thanks

Quick note first: the two .rar files can't be opened on this side (only metadata came through), so the only thing I can actually look at is 48v bateri_fix.bin. If you want the archives reviewed, upload the contents as plain .bin.

What the sampled file shows (facts)

• Size is exactly 128.00 KB = 1 Mbit, which matches an M95M01 ("5M01" top mark) SPI EEPROM. So the read size itself is correct for that chip.
• Only the low area carries data. From the sampled window at 0xFF40 all the way to 0x1FFFF the dump is solid FF. Some of these BMS only use the first blocks, but I can't confirm from a sample alone that nothing was lost — compare against your untouched original read to be sure.
• Header carries the ID strings 0009022255 at ~0x1B and 00090144090 at ~0x4C, plus the long record 200571074800090144090C9PE102000212A2T0000602 and 0009022255290001 (part no. + ZGS-style suffix).

The important part
Those ID strings are what decides whether a donor/"q" file will ever work. If the numbers in the file you tried don't match the numbers on your GLE53 BMS label (and the pack serial / cell configuration written alongside them), the BMS will either refuse the data or throw a config-mismatch DTC and lock again — that's the usual reason a borrowed file "does nothing". A 48V BMS EEPROM repair on these is normally done on your own dump: reset the lockout/fault flags and the error log, leave VIN, pack serial, HW/part IDs, cell count and calibration untouched, and recalculate the block checksums. Most of these layouts have per-block CRC — an edited file written without CRC fix is rejected.

Before writing anything else
Check the pack itself. After a 12V failure the classic result is a contactor/pyrofuse lockout, but if one cell module has dropped under threshold the BMS will simply re-latch the fault seconds after you clear it. Measure the individual cell/module voltages and the voltage at the pack terminals before/after a clear attempt — if EEPROM reset holds for a few seconds then drops out, the problem is hardware, not the dump.

What I need to take this further

• The original untouched read of the M95M01 (as .bin), not just the fix version — I need the delta.
• Full BMS label: A000... part number, ZGS / A-STAND, production number.
• Model year and engine (M256 GLE53, but which year / W167 facelift or pre-FL).
• Exact DTCs from Xentry/Vediamo in the BMS and in the 48V DC/DC, and whether the BMS answers on diagnostics at all.
• Tool and method used for the EEPROM read/write (in-circuit, desoldered, which programmer) and whether you have a verified read-back after writing.

Post the original dump and the label photo and we can compare it byte-for-byte against the "fix" file you tried.

dump is original ad files are patched oiginal

Good — that changes the approach completely. If 48v bateri.bin is your own original read and 48v bateri_fix.bin is that same dump after patching, then the fastest way forward is a straight byte diff of the two, not hunting for donor files.

What the sampled headers already show

I only have the stratified previews here (header/middle/tail windows), not a full byte-by-byte compare, but in the header window the two files differ in exactly three small spots:

• 0x04: FE (original) → FA (fix)
• 0x0A–0x12: 8B 13 03 19 FF FF FF FF 92 (original) → 04 12 07 04 00 00 00 01 E8 (fix)
• 0x7D: FF (original) → 00 (fix)

Everything else in that window is identical, including the ID block: 0009022255 at ~0x1B, 00090144090 at ~0x4C and the long record 200571074800090144090C9PE102000212A2T0000602. So the patch did not touch part numbers or the pack ID — that part is correct behaviour for a repair file.

Inference (not confirmed)

The FF FF FF FF → 00 00 00 01 at 0x0E–0x11 plus the FF → 00 at 0x7D look like a lock/fault status word and a flag byte being cleared, and 0x04 changing at the same time looks like the header checksum being recalculated. That is the shape of a typical lockout reset. Whether the checksum algorithm used was the right one for this BMS I cannot tell from a sample — if it is wrong, the BMS discards the block and re-locks immediately, which is exactly what "nothing changed" looks like on the bench.

Next steps

• Run a full binary compare (HxD → Analysis → Data comparison) of original vs fix and post the complete offset list. If the diff is limited to those few header bytes, the patch is a flag/checksum edit only and none of the cell/calibration data was disturbed.
• Before writing anything again: measure the 48V pack at rest and, if you can reach them, individual cell/module voltages. On these EQ Boost packs, if a cell has dropped under the permanent-disable threshold after the 12V failure, the BMS re-flags itself within seconds of power-up no matter what you write into EEPROM. That is the single most common reason a correct repair file "doesn't hold".

To go further I need:

• Exact model/year and BMS part number from the label (A000 900 xx xx) — you wrote GLE53 AMG, chassis C167 or W167, M256?
• How the M95M01 was read: in-circuit or desoldered, and with which programmer
• Was the fix file actually written already? If yes — what did the car do afterwards, and which DTCs are stored in the BMS and in the 48V converter after a clear + ignition cycle (Xentry screenshot)
• Resting voltage of the 48V pack

Also, please re-upload 48v bateri_fix typ2.rar as a plain .bin — RAR can't be opened on this side, so that variant is currently invisible to me.

immokill said:

hi need repair 48v Mercede GLE53 AMG battery eeprom 5m01 . Tried q files I will uliad.

thanks

Click to expand...

i tried firsy file add now it has dtc Actuator locked , batt is good 46v , i have lab charger for testing cells all ok, maybe this fiole is good. In first gile xentry didnt ask for serisl number nut x431 launch ask for batt number. I set time on mbux IC kombi and put manual Time and date after synced car with time. Gle53aamg 2021 matrix with ev active roll stabilization. 12V replaced .
Need good file.

Thanks

Thanks, that one came through fine — 48v bateri_fix typ2.bin opened, 128.00 KB, so I now have sampled windows from all three files.

What the sample shows (facts)

• IDs are identical in all three files: 0009022255 at ~0x1B, 00090144090 at ~0x4C, and the long record 200571074800090144090C9PE102000212A2T0000602. So neither patch touched part/pack identity — that part is correct.
• Both patched files share the same edit pattern versus your original in the header: 0x04 FE → FA, and 0x0E–0x11 FF FF FF FF → 00 00 00 01.
• The two patches are not the same edit. 0x0A–0x0D is 04 12 07 04 in _fix and 04 14 05 1C in typ2, and the byte at 0x12 is E8 vs E7.
• Structural difference: in typ2 the byte at 0x00 is C3 and the block at 0x7A–0x8B is framed with C3 (42 c3 | c3 10 21 3f 2a c3 | c3 10 21 3f 2a c3), while your original and _fix both use 69 there (42 69 | 69 11 2b 44 b8 69 ...).
• typ2 also has live data around 0x10030–0x1008F where the sampled window of your original and of _fix is solid FF — including a run of ten 50 bytes at 0x10050.

Inference (not verified)
The recurring bytes 69 / 5A / C3 / F0 are clearly record delimiters, not data — every record in the 0x10040 area is wrapped identically (5a 49 83 1a 00 5a, c3 af 10 c3, 69 18 dc 02 00 69, f0 2e 83 1a 00 f0). That looks like a four-slot rotating/wear-levelled record scheme. If that's right, typ2 isn't just your dump with flags cleared — it has the header record moved to a different slot tag and an extra record block written into an area that was erased in your original. The ten 50 bytes look like a table overwritten with a constant rather than real measured data.

Practical conclusion
Of the two, _fix.bin is the lower-risk candidate — it stays on the same slot tag as your original and only changes the header flag/check bytes. typ2 changes more and adds a record; if the BMS reads that as the newest valid entry, it will act on data that isn't from your pack. I can't tell from a sample whether either checksum was recalculated correctly, and a wrong checksum is exactly what "nothing changed on the bench" looks like.

Next steps

• Run a real three-way compare in HxD (original vs _fix, original vs typ2) over the whole 128 KB, not just the header — post the offset list.
• Write _fix first, then read the EEPROM back and compare the readback to what you wrote. If the BMS restores the old values, it rejected the block (checksum or slot logic) — that alone tells you which direction to go.
• Keep the untouched original archived before anything else.

To narrow it down, what I still need: exact DTCs currently stored in the BMS via Xentry (and whether it answers on CAN at all), model year of the GLE53, how the 5M01 is read/written (in-circuit or desoldered, which programmer), and whether you made these two patched files yourself or they came from someone else.

read my post up , in addapter multiprog

Got it — chip out, read in the Multiprog adapter, full 128 KB. That's a solid read method, so the dumps themselves aren't the suspect part. Two things worth doing on the bench anyway: read the chip twice and compare the two reads (must be byte-identical), and always read back after every write.

Where you actually are now

"Actuator locked" after writing the first file is progress, not a failure. It means the BMS is booting, running its own diagnostics and communicating — it is no longer sitting in the dead/no-output lockout you started with. That DTC on these packs is the contactor/relay branch: the BMS is refusing to close the main contactors, or it tried and the plausibility check failed. It is not, by itself, an EEPROM data error.

Facts from your own information

• Pack measures ~46 V and your lab charger check says the cells are healthy — so the block itself is fine and the missing 48 V output is a contactor-not-closing problem, not a dead pack.
• Xentry did not ask for a serial number, X431 does. That's a tool difference, not evidence of a fault: Xentry read the pack identity out of the module and was happy with it, the Launch routine just always prompts for it. So the identity data in the file is being accepted.
• 2021 GLE53 with EV active roll stabilization — that car has the 48 V system feeding ABC/EAWS as well, so a locked contactor will also throw suspension-side faults. Ignore those until the pack is closed.

Inference (not verified)
With cells good and IDs accepted, the usual reasons the BMS keeps the contactors open are: a stored crash/overcurrent/isolation event that still latches, a failed precharge (precharge resistor or the precharge FET/relay itself), or a contactor that has welded/failed open after the 12 V event. A repair file cannot fix the last two — that's hardware inside the pack.

Next steps, in this order

• Post the exact DTC codes from Xentry, not the plain-text description — plus the freeze frame. "Actuator locked" covers several codes and they point at different branches.
• In Xentry, open the BMS actual values: contactor status (main +/-, precharge), isolation resistance, individual cell voltages, SOC, internal pack temperature, and any "shutdown reason"/"last disconnect cause" parameter. That single list will tell us whether this is still software or hardware.
• Tell me which file is currently in the chip — the first _fix or typ2. They are not the same edit, and typ2 additionally has records at 0x10030–0x1008F where your original read is FF, so it matters which one produced the current DTC.
• Read the chip back now, with the car's current state, and upload that read as plain .bin. This is the single most useful thing you can post. If the read-back is byte-identical to what you wrote, the BMS never updated its own records. If it changed, the BMS is alive, writing its logs, and we can see exactly which bytes it set when it decided to keep the contactors open — that is how the real lock flag gets located instead of guessed at.
• Run the Xentry startup/teach-in routine for the 48 V battery after any EEPROM change, then clear faults with ignition cycled off/on for a couple of minutes in between.

Don't keep writing more donor variants at this point — every extra write moves the record slots around and makes the compare harder. Post the DTC codes, the actual values and the read-back and we'll go from there.