The Mercedes EQS That Locked Itself: Inside a P1C80 Battery Lockout — and How We Brought It Back

It came in the way they always do. On a flatbed, dead silent, 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, turned into a two tonne paperweight. The reason? Somewhere deep inside the high voltage battery, one single cell had quietly died.

The owner already had a quote in his hand, and it was for a whole new battery pack. 35 to 55 thousand euro, depending on which OEM workshop you walk into and whether they hand you a refurbished pack or a brand new one. That quote, like almost every quote these cars get, was wrong. And brutally overpriced. For one dead cell.

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.

And there is one more thing that matters more than anyone realises. Because we only clear the latch and leave every other byte exactly as the factory wrote it, the car stays a real, untouched Mercedes in the eyes of its own systems. The BMS keeps its original identity and calibration, which means the vehicle can still take future software updates, still go through a safety recall at an authorised dealer, and still run every single one of its protection and safety functions the way Mercedes designed them. Nothing is faked, nothing is grafted in. Go the Frankenstein route instead, with a donor BMS or a patched dump pulled off another car, and none of that is guaranteed anymore. The identity no longer matches, updates can reject it, and the safety chain you are trusting with a 400 volt pack and the people sitting on top of it is suddenly built on somebody else’s data. We do not do that, and we do not recommend anybody else does either. A battery is not the place to gamble.

*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 is smarter than that, and that cleverness is exactly where the trouble starts. This pack is built as a redundant parallel system. Two independent 400 volt strings sitting side by side, each with its own slave BMS, tied together through four contactors. One string on the right, one on the left. Each string is a chain of six modules, eighteen cells each, 108 cells in series per side. Two strings in parallel, that is the 2P in 108S2P. On paper it is beautiful. If one side gets in trouble, the system is built to notice it, isolate it, and protect the car. In practice, that same protection is exactly what leaves the car stranded.

Each string has its own slave BMS, an Infineon TC277T controller with a little ST M95M02 EEPROM bolted next to it. 256 kilobytes of memory that never forgets, where the BMS writes down everything it sees. Voltages, balancing counters, an internal resistance index for every single cell, and most important of all, its fault memory. That EEPROM is the black box. It is also the key to the whole job.

The moment it goes wrong

Lithium cells rarely fail with a bang. They fade. One cell in this pack, module I, cell 12 on the right string, slowly lost its grip. Its internal resistance climbed from a healthy 0.59 milliohm to around 1.8 milliohm, roughly three times its neighbours. Under load that weak cell sagged, then collapsed, dropping toward zero volts while the rest of the string sat happily at 3.82 V. The slave BMS watched that cell cross every threshold it had, logged violation after violation into the 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 mask 0x003F, meaning all six modules flagged, written twenty two times over as the cell was dying. The master gateway reads that latch, raises P1C80, HV component lockout active, and opens the contactors for good. From that moment the car refuses to close the high voltage system. No charging, no driving, and the 12 volt battery slowly bleeding flat in the background. Here is the cruel part. Because the fault lives in non volatile memory, a normal diagnostic reset does nothing. You can clear P1C80 with a tester a hundred times. On the next wake up the BMS reads the latch straight back out of its EEPROM and locks the car again. The pack is holding itself hostage with its own memory.

And it gets worse. OEM will not sell you a separate BMS, or any individual part of the HV battery. So even if you solve the root cause, you still cannot start the car, because the BMS stays locked. Technically, without EV Clinic, this battery is a write off.

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, top and bottom, and decode them byte by byte. The two dumps told the story straight away. The bottom string’s fault latch was completely clean. All zeros, no lockout, cells balanced, resistance nominal. The top string was the casualty. Latch set, twenty two lockouts, and a voltage violation history showing a cell dragged all the way down to about 1.53 volts before the contactors opened. Only one BMS had latched. The other just went along for the ride.

The data no scan tool will ever show you

This 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 few 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 on the diagnostic bus at all. They live only inside 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 pull the whole timelapse of the failure, and we can see every other cell’s resistance and how it behaves under load. It is not always an obvious issue like a discharged cell. Internal resistance can show you the next cell about to go, the one you need to sort out now, while the pack is already open on the bench.

When we dumped this pack, the raw data laid out the whole timeline. The BMS had 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 in slow motion. First a short 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 starts to sag under load at -335 A, 2788 mV, and over the next eight hours it collapses step by step. 2775, 2567, 2280, and finally 1534 mV, while every other cell in the string sits 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 module we measured by hand, that gives us a full resistance map of the pack in milliohm, the most honest measure of cell health there is. Cell 12 lit up at 1.80 mΩ, three times its neighbours at 0.59. But the same map also caught cell 88 climbing to 1.44 mΩ, and on the opposite string cells 43, 70 and 77 starting to drift. Future failures, caught today, that no code and no voltage reading would ever have shown. 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 keep an eye on next.

Where the codes come from

With the physical picture in hand, the stored 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 under the P1C80 lockout. Every one of them matched 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

Here is the plan on this pack. We change two modules and balance the voltage to the rest of the right string. The left string is fine, just discharged down to 0% SOC. The faulty right string had already detached itself from the pack at around 60%, the moment one cell dropped into a low SOC state.

Recovery is two moves, and the order matters. First the hardware. The failed cell is replaced, the module is brought back into balance, and the developing weak cell is dealt with 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 the inner CRC32 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, and P1C80 is gone. For real this time, because the thing that was storing it is finally telling the truth.

Now we are waiting on brand new modules from Poland to install into the battery and finally run the car without any locking faults, and with more range.

That whole 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 redundant parallel architecture and its non volatile fault latching are brilliant engineering. They protect the car and the people inside it. But they also mean that one single failing cell can lock an entire battery in a way that looks, to anyone without the data, like a total loss. It is not. 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.