It arrived the way these cars always do — on a flatbed, silent, with a red battery warning frozen on the dash and a “Stop vehicle safely” message that nobody at the dealer could make go away. A Mercedes EQS, the V297, one of the most advanced electric sedans ever built, reduced to a two-tonne paperweight because somewhere deep inside its high-voltage battery a single cell had quietly died. The owner had already been quoted a new battery pack. That quote, as it usually is, was wrong and expensive. Price range vary from 35k till 55k. (different prices in different OEM workshops – indicating offer from refurbished to new)
This is the story of how an EQS locks itself out, why the P1C80 fault is so stubborn, and how we recover these packs at the cell level instead of throwing the whole thing away. If you only want the tool, it lives here: https://evclinic.eu/eqs-slave-bms-error-clear-p1c80/. If you want to understand what actually happened inside the battery, keep reading — because the EQS fails in a way that tells you exactly how clever, and how unforgiving, its battery management really is.
*system fully disconnected to 60V components.

A battery that is really two batteries
Most people picture an EV battery as one big block. The EQS pack is smarter than that, and that cleverness is the root of the whole problem. Inside, it is built as a redundant parallel system — two independent 400-volt strings wired side by side, each with its own slave BMS, joined through four contactors. One string sits on the right, one on the left; each is a chain of six modules, eighteen cells apiece, 108 cells in series per side. Two strings in parallel is where the “2P” in 108S2P comes from. On paper it is beautiful: if one side has trouble, the architecture is designed to notice, isolate, and protect. In practice, that same protection is exactly what strands the car.
Each string is watched over by its own slave BMS, running an Infineon TC277T controller with a little ST M95M02 EEPROM bolted to it — 256 kilobytes of non-volatile memory where the BMS writes down everything it sees. Voltages, balancing counters, internal-resistance indices for every cell, and crucially, its fault memory. That EEPROM is the black box. It is also the key to everything.
The moment it goes wrong
Lithium cells don’t usually fail with a bang. They fade. One cell in this pack — module I, cell 12 on the right-hand string — slowly lost its grip, its internal resistance climbing from a healthy 0.59 milliohm to around 1.8 milliohm, roughly three times its neighbours. Under load that weak cell sagged, then collapsed, eventually falling toward zero volts while the rest of the string sat happily at 3.82 V. The slave BMS watched the voltage of that cell cross every threshold it had, logged violation after violation into its EEPROM, and then did the one thing it is built to do when a cell goes out of bounds: it latched.
Latching is not a normal fault. When the slave BMS writes a lockout, it stamps a code and a module mask straight into the fault-latch block of the EEPROM — in this car, code 0x000E with a mask of 0x003F, meaning all six modules flagged, written twenty-two times over as the cell died. The master gateway reads that latch, raises P1C80 — HV component lockout active — and opens the contactors for good. From that instant the car refuses to close the high-voltage system. No charging, no driving, the twelve-volt battery slowly bleeding flat in the background. And here is the cruel part: because the fault is stored in non-volatile memory, a normal diagnostic reset does nothing. You can clear P1C80 with a tester a hundred times; the BMS reads the latch back out of its EEPROM on the next wake-up and locks the car again. The pack is holding itself hostage with its own memory.
OEM do not sell seperate BMS or any individual parts of HV Battery, that means in any case you solve root cause, you wont be able to start the vehicle due BMS lockut, so technicaly, battery is write off if EV CLINIC do not exists.
Reading the black box
This is where most workshops stop and the dealer reaches for a new pack. We do the opposite — we read the memory. We pull the EEPROM dumps from both slave BMS units, the top and the bottom, and decode them byte by byte. The two dumps immediately told the story. The bottom string’s fault latch was completely clean — all zeros, no lockout, cells balanced, resistances nominal. The top string was the casualty: latch set, twenty-two lockouts, the voltage-violation history showing a cell dragged down to about 1.53 volts before the contactors opened. Only one BMS had latched. The other had simply gone along for the ride.
The data no scan tool will ever show you
Here is the part that separates reading a battery from guessing at one. Plug a dealer tester into an EQS and the best you get is a list of stored codes — P1C80, a handful of module faults, maybe a “replace battery” flag. It tells you something is wrong. It will never tell you what, because the values that actually explain the failure are not exposed on the diagnostic bus at all. They live only in the slave BMS EEPROM, and the only way to see them is to decode that memory byte by byte — which is exactly what we do.
With this we can find timelaps of faulty progress and we can see all other cell resistance and faulty behavior under the load, because it is not always obvius issue like cell discharge, IR could show you next potential failure which you need to sort it out now while battery pack is open.
When we dumped this pack, the raw data told the whole timeline. The BMS had quietly frozen every voltage violation with a timestamp, the exact cell, the measured voltage, the string current and the cell temperatures. We could watch the failure happen in slow motion: first a brief overvoltage blip on cell 88 in module M, 4211 mV at 123 amps and 35 °C — a warning shot. Then, 38 hours later, cell 12 in module I starting to sag under load at −335 A, 2788 mV, and over the next eight hours collapsing step by step — 2775, 2567, 2280, and finally 1534 mV — while every other cell in the string sat untouched at 3.82 V. No diagnostic tool on earth prints that table. We pulled it straight out of the chip.
And it goes deeper than voltage. The EEPROM also stores a per-cell internal-resistance index for all 108 cells of each string. Decoded and calibrated against a measured module, that gives us a full resistance map of the pack in milliohm — the single most honest measure of cell health there is. Cell 12 lit up at 1.80 mΩ, three times its neighbours’ 0.59 mΩ. But the same map also flagged cell 88 climbing to 1.44 mΩ, and on the opposite string, cells 43, 70 and 77 beginning to drift — future failures, caught today, that no code and no voltage reading would have revealed. This is the barebone data: the raw, pre-diagnostic truth the battery writes about itself and never shows a scanner. Once you can read it, you stop replacing packs on suspicion and start repairing the one cell that actually failed — and you can tell the customer exactly which cells to watch next.
Where the codes come from
With the physical picture in hand, the stored diagnostic codes finally make sense instead of being a wall of hex. The module voltage faults P0F18 and P0F64, the cell-sensor faults P0B63, P0B64, P0B67 and U357D, the low-SOC early warning P1540, all sitting underneath the P1C80 lockout — every one of them correlated exactly with what the resistance map and the freeze frames already showed. The EEPROM and the multimeter agreed down to the individual cell. That is the difference between a code reader and a diagnosis: a code reader tells you the battery threw P1C80; the data tells you module I, cell 12, three times resistance, collapsed under a 335-amp load over two days. One leads to a thirty-thousand-euro guess. The other leads to a repair.
Bringing it back
We will change 2 modules, balance the voltgate to the rest of the right side of battery pack, while left is ok but discharged to 0% soc. While defect one deatached from the pack aroun 60% while one cell went into low soc state.
Recovery is two moves, in order. First the hardware: the failed cell is replaced and the module brought back into balance, and the developing weak cell is addressed before it becomes the next breakdown. There is no point clearing a fault on a battery that is still broken — the BMS would just latch again, and it would be right to. Only once the string is physically healthy do we touch the memory. Then we take the EEPROM dump, zero out the latched lockout in both redundant copies, recompute the CRC16 and inner CRC32 checksums so the BMS accepts the block as genuine, and write it back. The slave BMS wakes up, reads a clean fault memory, the master closes the contactors, P1C80 is gone — for real this time, because the thing that was storing it is finally telling the truth.
Now we are waiting brand new modules from Poland to install into battery and finally run the car without any locking faults and with more range.
That EEPROM decode-and-reset is exactly what our online EQS BMS recovery tool does. You upload the top and bottom slave BMS dumps, it decodes the latched DTCs, the freeze-frame voltages and the full internal-resistance map, shows you which cell and module actually failed — and which are about to — and builds the clean, fault-reset binary ready to flash back. No dealer, no full-pack replacement. You can run it here: https://evclinic.eu/eqs-slave-bms-error-clear-p1c80/.
Why this matters
A dead cell is a hundred-euro problem wearing a thirty-thousand-euro disguise. The EQS’s redundant parallel architecture and its non-volatile fault latching are brilliant engineering — they protect the car and the people in it — but they also mean that a single failing cell can lock an entire battery in a way that looks, to anyone without the data, like a total loss. It isn’t. The pack remembers everything, and once you can read what it remembers, a locked EQS stops being a write-off and becomes a repair. That is the whole philosophy behind EV Clinic: component-level, data-driven, keep the pack, fix the cell, clear the fault honestly.
If you’ve got a Mercedes EQS stuck on P1C80, an HV system fault that won’t clear, or a pack that locked out after a deep discharge, start with the dumps — and start here: https://evclinic.eu/eqs-slave-bms-error-clear-p1c80/.












Absolutely exciting to read how you can find the root cause and solve the problem by digging deep into the architecture and EEPROM content.
While I appreciate that you publish such details of your work, don’t you think there is the risk of Mercedes engineers reading your article too and introducing EEPROM encryption or other obstacles in their next design?
Had this car already traveled more than 250 000 kilometers and therefore lost the factory warranty on the battery?
Why do you consider the dual-string battery design redundant and brilliant, if a single cell failure on one string still immobilizes the car?
They alrady did that under EU directive to lock BMS, Cyber secuirty act from 2017