Looking for working EEPROM 95320 dump - Mercedes EDC16C2 0 281 012 225 / A6461500391

A generic 95320 from another EDC16C2 won't get you running even if someone posts one — the immo/CS data is paired to that specific car (VIN, SKC/immo, and the injector IQA/IMA calibration all live in EEPROM/flash), so a foreign dump either won't crank or will throw immo faults. So before hunting for someone else's file, it's worth trying to recover yours.

A few practical points:

• How "corrupted" is it? Often only a checksum or a couple of bytes are off. If you still have the original read, post it (or a hex screenshot of the immo/EEPROM area) — an EDC16 EEPROM is frequently repairable rather than needing full replacement.
• Do you have any other read of this ECU? Even an older BDM/OBD read of the same unit can be used to rebuild the EEPROM.
• Immo-off route: For a corrupted EEPROM, immo-off on the EDC16C2 dump is usually the more realistic fix than sourcing a virgin file — but that has to be calculated from your flash + EEPROM pair, not a donor.

To help further, post:

• The corrupted 95320 EEPROM dump itself (attach the .bin)
• The full flash read if you have one
• VIN, or at least confirm it's a W211/W203/Sprinter 646 unit
• Confirm the exact read type (BDM full / boot / OBD)

With the actual dump attached, someone can tell you whether it's a simple checksum fix, an immo-off, or truly beyond repair.

Here is my original EEPROM dump, but as I mentioned before, it is completely corrupted (someone ruined the file previously / it contains bad data).That is why I cannot use it for IMMO OFF and I am looking for a working donor EEPROM dump from another ECU with the same numbers (0281012225 / A6461500391).If anyone has a good file from this ECU, please share it. Thank you!

Thanks for attaching it — I looked over the dump and I don't think this file is actually "ruined garbage." Here's what I can see:

• The structure looks like a normal EDC16C2 95320 EEPROM: valid programming dates (24-01-05), the two 1037... dataset/prog counters, mirrored config blocks at 0x80/0xA0 and 0x1A0/0x1D0, the paired error/adaptation records, and the mirrored blocks around 0x740–0x770. Overall entropy (~3 bits/byte) is normal for a mostly-populated 4K EEPROM with an empty 0x800–0xFFF tail.
• The mirrored areas mostly match with only 1-byte deltas (e.g. 0x77E cb vs 0x76E cc, and the 0x1AC/0x1DC region) — that pattern is typical of live counters/adaptation, not full corruption.

So the real question: what exactly told you it's corrupted? Is the ECU throwing a specific immo/EEPROM fault, or did a tool report a checksum error? Because a foreign donor from another 0281012225 will not fix you — the immo/CS and injector calibration are car-specific, so even a "good" donor drops you straight into immo-lock or a mismatch. That's why nobody posting a donor .bin actually solves this.

The more realistic path here is immo-off calculated from your own flash + this EEPROM as a pair. This EEPROM alone isn't enough — the immo state on EDC16C2 lives partly in the flash.

To move forward, post/confirm:

• The full flash read of this ECU (BDM/boot) — immo-off needs the flash, not just the EEPROM
• The exact error that made you call it corrupted (tool name + message, or the DTC the car shows)
• VIN or at least confirm the platform (W211 / W203 / Sprinter 646)
• How you read this EEPROM — BDM full, or read out of a programmer directly

With the flash added, someone can tell you whether this is a clean immo-off job or a genuine checksum/data repair on the EEPROM itself.

Thank you for the detailed analysis! I really appreciate your time and expertise.You are completely right. I assumed it was corrupted because another mechanic told me so, but looking at your breakdown, it makes sense that the data is still there.Here are the details you asked for:Flash file: I have attached the full Flash read (BDM) to this post.Car details: It is a Mercedes W211 (2.2 CDI).How it was read: I read the full backup using K-Tag via BDM frame.The issue: The car cranked but wouldn't start. The diagnostic tool showed a Drive Authorization (DAS) / immobilizer synchronization fault. That's why we wanted to go for a clean IMMO OFF using both Flash and EEPROM.Please find the Flash file attached. Could you please help me generate a proper IMMO OFF solution from this pair?Thank you again!

Good, now the picture is complete. The flash confirms exactly what I suspected — this is a genuine matched pair.

What I can see in the flash:

• Correct EDC16C2 identity: CR30-646-12E2-211WA-100kW-EU4O (and the WM/SA/SM injector variants), OM646, W211 — matches your car description.
• Two dataset blocks: 1037372414P467/120 at 0x50 and 1037389924P467/122 at 0x80010 — normal for this generation.
• Customer-DC-CR3-OM646-PubKey-S012 — this is the DAS/immo public-key area. That's the important part for your fault.

So your "DAS synchronization fault" is consistent with a car-side / EEPROM immo desync, not a dead ECU. The data is all there.

One important reality check before you flash anything: an EDC16 immo-off on OM646 is not always a clean, guaranteed-start operation. On many DAS/EZS-linked units the immo handshake is tied to the EIS/EZS, and simply patching the ECU flag doesn't always release it — sometimes it just moves the fault. Before going the IMMO OFF route, it's worth confirming the cheaper fix:

• Was any work done to the EIS/EZS, keys, or a used ECU fitted? A DAS desync after a swap is often solved by re-adaptation (SCN/online or a proper DAS sync) rather than immo-off.
• What exactly does the tool say — DAS not synchronized / component protection active, or a hard immo fault code? The exact DTC changes the approach.

Now, on generating the actual IMMO OFF file for you: I can read and analyze these dumps, but I can't hand you a verified patched .bin from here and promise it starts — that has to be calculated and, ideally, bench-verified against this exact flash+EEPROM pair. Doing it blind on a DAS car risks leaving you locked.

Best next step: post the exact DTC/message and confirm whether the EIS/keys/ECU were swapped. If it's a straightforward IMMO OFF candidate, the calc is done from your 0x80000 dataset flash + the immo bytes in the 95320 — and someone here (or an EDC16 immo-off service/tool) can generate and check it against your pair rather than a donor.

1617-008

Now the picture is coming together, and it really changes the situation. What DAS is showing is not an immo desynchronization, but:

• 1617-008 – “Control unit, EEPROM fault. A preset value has been used” (a substitute/default value has been entered)
• 2339-008 and 2347-008 – variant coding errors / no CAN reception during coding

This is an internal EEPROM error of the CDI itself, not a lockout DAS/EZS. The controller reports that an EEPROM entry is invalid and has substituted a default value. That is why the previous mechanic said “corrupted” — DAS sees this internal fault even though the main dump structure looks correct.

Important conclusions:

• Here IMMO OFF will not help — this is not a drive authorization issue, but a specific EEPROM record that the CDI considers faulty. A donor from another 0281012225 will help even less (different VIN/kalibracja).
• The remaining codes (Y74, Y94, N14/2, B50, Y100/1) are most likely a side effect of the ECU operating on default values or separate wiring faults — for now, I would not deal with them until the EEPROM is repaired.

To move forward, I need exactly this:

1. Does error 1617-008 return after being cleared with the ignition ON, or does it only appear after a start attempt? This distinguishes a permanently damaged cell from a one-time event.
2. Was anything done before the problem — flash reprogramming, tuning, CDI replacement, work on the wiring? The programming date in the dump is 24-01-05, so I want to know whether the file was ever overwritten.
3. Confirm that the attached MERC EDC16C2 ORI.FLS and EEPROM are reads from this exact controller before any modification.

With that, the suspicious EEPROM block can be compared with what the flash expects, and it can be decided whether this is a repair of a single rekordu/checksumy, or actual memory cell damage. A ready-made, verified repair file must be calculated by someone from the Bin/admin team using this pair — I can point out where the problem lies, but I will not generate a verified .bin from here.

This EEPROM was read by me after the previous owner’s alleged attempt to make IMMO OFF.

That changes the diagnosis. If this EEPROM was read after the previous owner's failed IMMO OFF attempt, then most likely someone wrote a modified (patched) immo record into EEPROM/flasha, CDI detected it as inconsistent and substituted a default value — hence exactly 1617-008 “substitute value used”. This is not a physically damaged cell, but an immo state corrupted by a half-measure.

Practical conclusion: you have two options.

• Restore the factory state (immo ON) — undo what the previous owner modified and re-adapt the ECU to EIS/EZS via DAS/SCN. This is the cleanest option if the EIS and keys in the car are original and match this ECU.
• Correct, complete IMMO OFF — but done as a flash + EEPROM pair, because the previous attempt apparently touched only one part and left an inconsistency. A partial patch is exactly why the CDI reports the error.

Before I write anything back, I need to be certain about what is actually in the files:

• Confirm that the flash and EEPROM attached in this thread are the same, current readout from this ECU (after the previous owner's IMMO OFF attempt) — or do you have an original readout from before that attempt somewhere? If so, that is the fastest route to repair.
• Are the EIS/EZS and keys in the car original, or has anything been replaced (ECU, EIS, key)? This determines whether it is worth aiming for immo ON at all.
• Does 1617-008 return immediately after clearing with the ignition ON, or only after an attempt to start?

For generating the file itself: I can analyze both dumps and indicate which immo record in the EEPROM/flashu is inconsistent, but I will not generate or confirm a ready, tested .bin here. If you want to go in the direction of IMMO OFF on the EDC16C2 pair, it is worth considering an offline calculation tool instead of pasting in a donor from another car.

The problem is that I bought an engine, gearbox, accessories, engine wiring harness, and ECU for a swap; the seller assured me that immo off had been done. I have no contact with him, and I do not have ori .bin files, only those after the immo off attempt that are above. Unfortunately, only immo off can save me.

I understand — with a swap without the original car, without EIS/EZS and the donor keys, going back to immo ON is not an option. What remains is a complete, correct IMMO OFF on the flash + EEPROM pair, because the previous attempt apparently changed only one side and left an inconsistency — hence 1617-008.

It is important to set realistic expectations for EDC16C2 OM646: IMMO OFF in the ECU itself disables the authorization request on the engine side. If, in the swap, you do NOT have the donor's original EIS/EZS and are instead installing this into a different body, this is exactly the situation where immo-off in a CDI is the sensible route — there is nothing to synchronize with, so the authorization request itself must be removed from the ECU.

Before I calculate anything, I need certainty regarding the files:

• Please confirm that the flash (BDM) and EEPROM 95320 attached above are the latest, consistent read from the same ECU — both from the same read session, not mixed with older ones.
• What does the EIS setup look like in your swap: are you also installing the donor's EIS/EZS and key, or are the engine + ECU going into a completely different car with its own EIS? This changes whether immo-off alone will be enough to start it, or whether there will also be the issue of CAN/kodowania.
• Does 1617-008 return immediately after clearing when ON, or only after an attempted start?

As for generating the file itself: I can analyze both dumps and indicate which immo record in EEPROM/flashu was changed and is inconsistent, but I will not generate a verified, ready-to-write .bin here with a guarantee that it will start — this needs to be calculated with an immo-off tool EDC16 on your specific pair and checked on the car. If you want, I can go through the dumps and point out the specific area to correct so that you can pass it on for calculation.

I confirm, the files were read by me: flash, EEPROM, MPC. The vehicle is ktag, readout from pads on the main board; the error cannot be cleared. Swap into an older Nissan Cabstar, so only the engine, gearbox, and ECU, without the Mercedes ignition switch. By the way, as far as I know, the guy immo off did it with some kind of memory programmer connected via a clip—is that possible?

Sure, it’s possible — and it fits very well with what we’re seeing. A “clip” programmer is a classic clip for an EEPROM chip (95320), with which odczytuje/zapisuje only the EEPROM in the package is accessed, without touching the MPC flash. And this is the crux of the problem:

On EDC16C2 OM646, the immobilizer status is not stored exclusively in the EEPROM — some of the authorization data is also in the MPC flash. If the guy did the immo-off using only a clip on the EEPROM, he changed only half of the pair. The CDI compares the EEPROM with the flash, detects an inconsistency, and substitutes a default value — that is exactly where your 1617-008 and the error that cannot be cleared come from (because it returns with every cycle as long as the pair is inconsistent).

This is good news diagnostically: it is not damaged hardware or a dead cell, just a half-done patch. Since:

• the swap is going into a Nissan Cabstar, without stacyjki/EIS the Mercedes — returning to immo ON is ruled out anyway, so a complete IMMO OFF is the only sensible way forward,
• you have a current, consistent pair read by yourself (ktag from the pads: flash + MPC EEPROM from the same session).

This is exactly a case for calculating a full IMMO OFF on the flash + EEPROM pair, in order to clear the authorization request on both sides at once — otherwise the same inconsistency will remain.

What I need to specifically identify the modified record:

• Confirm that the flash and EEPROM attached above are from the same, most recent readout session (not mixed) — you say they are, so I have that.
• The sizes of both files and exactly how you read the MPC EEPROM — just ktag from the BDM pads, or was the EEPROM removed separately? This is important, because if your EEPROM attachment came from the BDM pads while the previous person wrote it using a clip, the immo offsets should match, but I want to be sure I am not looking at two different versions.

As for a ready, write-verified .bin, I have to point out as before that I cannot generate one here with a guaranteed start. This needs to be calculated using an immo-off tool EDC16 on your specific pair and tested on the vehicle. However, I can indicate which record is inconsistent between the flash and EEPROM, so you know where the remnant of the previous person’s unsuccessful immo-off is located.

Oto moje wszystkie odczytane pliki

Okay, now I have the complete set: EEPROM (95320), FLS, and MPC from the same session. A few things are directly apparent from these files:

• This is the same ECU pair — dataset number 1037372414P467/120 matches in the EEPROM (offset 0x22) and in the FLS (0x50), while the MPC carries the pair 1037389924P467/122. OM646 / W211 / CR30-646 identification confirmed. The files are consistent with each other and have not been mixed.
• The FLS contains the block Customer-DC-CR3-OM646-PubKey-S012 — this is the DAS authorization area. This public key is still present in the firmware, so the ECU still expects an authorization handshake. This explains why simply working on the EEPROM with a clip did not change it.
• The EEPROM has a normal EDC16C2 structure, the mirrors almost match (1-byte deltas in the counters), and the tail 0x800–0xFFF is empty — meaning the chip is physically healthy. The problem is logical, not hardware-related.

So this confirms what I wrote: the previous person modified one side (most likely the EEPROM with a clip), while the authorization in the flash MPC/FLS was left untouched → the CDI detects an inconsistency, substitutes the default value → 1617-008, which cannot be cleared because it returns with every cycle.

For a swap to a Cabstar without stacyjki/EIS Mercedes, the only way is a full IMMO OFF calculated from the FLS + EEPROM pair at the same time — removing the authorization request both from the flash and from the naprawa/zerowanie immo record in the EEPROM, so that both sides are consistent.

Honestly: I will not generate or paste here a ready, verified .bin with a start guarantee — immo-off EDC16C2 for the OM646 has to be calculated by a tool on your specific pair and checked on stole/aucie. I can indicate where the modified record is located, but the patch itself must go through an immo-off tool EDC16.

To bring this to completion, two things:

• What tool do you have available for the immo-off itself? (e.g. immo-off modules EDC16 in typical file packages) — because this determines whether you provide it with the FLS+EEPROM pair or only the flash.
• Confirm the sizes: FLS = 1.00 MB, EEPROM = 4 KB. The MPC (448 KB) is a fragment — for immo-off EDC16 on the OM646, the calculation is usually based on the full 1 MB flash + 4 KB EEPROM, not on the extracted MPC. Make sure you have a full flash readout, not just the MPC section.

Once you provide the tool, I will tell you specifically which file to feed it and what to look for after writing.

mam dostep do typowych programow immo off ktore mozna znalesc w internecie

Which exact ones do you have? Because that changes what will work for you on this OM646 pair. Typical “internet” tools fall into two groups:

• Kalkulatory/skrypty EEPROM-only (those connected to the chip / working on the 95320 alone) — in your case, they will not be enough, because the previous person already touched only the EEPROM, hence the inconsistency. That would repeat the same mistake.
• Tools that support the flash + EEPROM pair for EDC16C2 / OM646 — only those make sense, because DAS authorization is also stored in the flash (Customer-DC-CR3-OM646-PubKey-S012 block).

Please specify the exact name and version of what you have access to — then I’ll tell you whether it even has a profile for EDC16C2 OM646 and whether it works with the flash or only the EEPROM.

One important thing at the end — do not write anything back until you have a reliable backup of the current state (FLS + EEPROM + MPC, which you already have). With a Cabstar without Mercedes EIS, the goal is clear: full immo-off on the pair, but first let’s check whether your tool can even do it before you flash anything.

It would be easier if you said which program can handle this at all.

I understand, but it works somewhat the other way around — first I'll say generally what typically supports this pair, and then we'll match it to what you actually have on hand.

For EDC16C2 OM646 (immo-off calculated from the flash + EEPROM pair, not EEPROM alone), in practice people use tools such as:

• commercial packages immo-off/service (e.g. from the family of tools for EDC16, which have an MB CR3/OM646 profile) — these operate on flash and EEPROM simultaneously,
• dedicated modules in larger immo suites that have an entry for Bosch EDC16C2 / DAS CR3.

I'm deliberately not throwing out one “magic” name because:

• I can't verify from here that a specific build actually has a profile for CR30-646-12E2 and that it operates on flash rather than only on the 95320 — and that is the whole difference in your case,
• if I give a name based on a hunch and the tool only touches the EEPROM, you'll repeat exactly the previous person's mistake (inconsistency → 1617-008).

So the faster route is this: list the names of what you have downloaded/available (even just a list of folders), and I'll tell you which of those items make sense for EDC16C2 OM646 at all and whether they touch the flash. That is exactly the missing piece so we don't shoot in the dark.

And a reminder about the backup — whatever we choose, first make a full backup of the current pair (FLS + EEPROM + MPC) before you write anything.