Need Original CAS3 Internal Flash Dump (MC9S12XDP512 0L15Y) – BMW E87 2011 118d – 61.35-9237047-01

Post #1

rockzt888r

rockzt888r

Stock Member
Thread Owner
Philippines
Joined
05.08.2026
Messages
6
Reaction score
0
Location
Philippines
Hi everyone,

I'm hoping someone can help me recover my CAS module. I'm looking for an original internal flash dump (512 KB) from a matching CAS3 module. If anyone has the same CAS on the bench and is willing to donate the flash dump, I would be extremely grateful.

Vehicle Information:

Vehicle: BMW 320d
Chassis: E90 LCI
Model Year: 2011
Engine: N47 Diesel
Transmission: Automatic
VIN: WBAUD71060P495192

CAS Module Information:

Module: CAS3
Manufacturer: Siemens VDO
BMW Part Number: 61.35-9237047-01
Siemens Number: 5WK4 9515EBR
Software Version:
MCV: 00.00.00
FSV: 2.6.4
OSV: 3.3.0
HW/SW/Coding/Diag Index: C4 / 21.2 / 09 / 06A0
MCU: Freescale MC9S12XDP512
Mask: 0L15Y
Internal Flash Size: 512 KB
EEPROM: 95320 (4 KB)

Original Data:

VIN: WBAUD71060P495192
Mileage: 46,253 km
CAS ISN: 62B4AAF4
EEPROM: Verified and appears to be intact.

What Happened???

While attempting to back up and rewrite the internal flash using XPROG 5.55, I encountered a communication error during programming. After correcting the solder connections, I was able to read and write the EEPROM successfully, but the internal flash appears to have become corrupted or incompletely programmed.

The EEPROM decodes correctly with:

Correct VIN
Correct ISN
Correct mileage
Valid keys

However, the CAS no longer boots.

Current Symptoms:

CAS has no communication via INPA/ISTA.
INPA reports IFH-0009: No response from control unit.
Key will not lock into the ignition slot.
Vehicle is completely dead.
No ignition (Terminal 15).
Windows, lights and other body functions are inoperative.
Instrument cluster only briefly displays the stored mileage when the cluster test button is pressed.
ELV cannot be detected because the CAS is offline.

Programmer Used:

Programmer: XPROG 5.55
Connection: Direct BDM solder connection
Power: XPROG adapter only (bench programming)
MCU: MC9S12XDP512 (0L15Y secured)
EEPROM: Successfully read and written
Flash: Programming reports success, but subsequent reads often result in "Device is silent".

What I'm Looking For:

I'm looking for a 100% original 512 KB internal flash dump from the same CAS module:

BMW Part No.: 61.35-9237047-01
Siemens VDO 5WK49515EBR
CAS3
MC9S12XDP512
0L15Y

The VIN and ISN do not have to match my vehicle. I only need a known-good original flash so I can compare it with my backup or attempt to recover the module.

If anyone has this exact CAS on the bench and can share the original 512 KB internal flash, I would sincerely appreciate your help.

Thank you in advance to anyone willing to assist.
 

Attachments

  • BMW CAS MODULE.webp
    BMW CAS MODULE.webp
    51.1 KB · Views: 3
Ratings and Reviews
Total ratings: 0
Sort by date Sort by votes

Post #2

Good news first: since your EEPROM (95320) is intact and decodes correctly with the right VIN, ISN, mileage and valid keys, this is fully recoverable. A donor internal flash from any matching CAS3 will get you booting again, because the flash holds only the program/OS — all car-specific data lives in the 95320. You do not need a VIN-matched flash, only a version-compatible one.

The key point for a clean recovery: match the flash to your firmware level so the flash and EEPROM structures agree. From your label:

  • MCU: MC9S12XDP512, mask 0L15Y
  • FSV 2.6.4 / OSV 3.3.0
  • HW/SW/Cod/Diag index: C4 / 21.2 / 09 / 06A0
  • P/N 61.35-9237047-01, Siemens 5WK4 9515EBR

A donor flash from the same 5WK49515 / 9237047 family with the same OSV 3.3.0 is the safe choice. If you flash a different OSV, the EEPROM layout expectations can differ and you may have to update/realign the EEPROM afterward.

A couple of things worth checking before you assume the flash is the whole problem:

  • Your original XPROG error happened mid-write. Confirm your solder/BDM connection is now solid and stable — a marginal BDM link will corrupt the write again. Re-seat, reflow, verify continuity on all BDM lines and power.
  • After writing the donor flash, do a full read-back and verify against the file. Don't trust "write OK" alone.
  • Make sure the secure/protected sectors and the D-Flash region are handled the way XPROG expects for this MCU — a partial-only write is often what leaves it dead.

To help you get the right donor and confirm whether you also need any post-flash EEPROM adjustment, can you confirm:

  • Exactly what XPROG wrote — full internal flash only, or flash + D-Flash/EEPROM?
  • Does XPROG still see/ID the MC9S12XDP512 over BDM now, or does the read fail too?
  • Do you still have your original (corrupted) flash read, even partial? Even a bad dump helps confirm region sizes.

Post those and someone with a matching 3.3.0 dump on the bench can line it up for you.
 
Upvote 0 Downvote

Post #3

Thanks for the detailed response. I appreciate the guidance.

Here are the answers to your questions:
  1. Exactly what XPROG wrote — full internal flash only, or flash + D-Flash/EEPROM?
Initially, I wrote the internal flash (P-Flash) only. After that, I restored my original EEPROM (95320) separately. The EEPROM now matches my original backup bit-for-bit, and it decodes correctly with the original VIN, ISN, mileage (46,253 km), and keys.

  1. Does XPROG still see/ID the MC9S12XDP512 over BDM now, or does the read fail too?
The behavior is intermittent.
  • XPROG can still identify the MC9S12XDP512 (0L15Y) and access the EEPROM.
  • EEPROM read/write/verify completes successfully.
  • Flash access is unreliable. Sometimes it reads, but other times it stops at "Bypass Security" or reports "Device is silent" during the flash read.
  • After writing, readbacks showed that large portions of the first 512 KB remained erased, which suggests the flash is not being programmed completely.
  1. Do you still have your original (corrupted) flash read, even partial?
Yes. I still have:
  • My original 512 KB internal flash backup.
  • My original 2 MB XPROG-format flash backup.
  • Multiple flash readbacks taken after programming.
  • The original EEPROM.
  • The restored EEPROM.
I've compared them extensively. The EEPROM is confirmed good.
The problem is isolated to the internal flash. Readbacks after programming never match the original flash, and the CAS remains completely offline:
  • No CAS communication in INPA (IFH-0009)
  • Key does not lock into the slot
  • No Terminal 15
  • Vehicle completely dead
The CAS information is:
  • BMW Part Number: 61.35-9237047-01
  • Manufacturer: Siemens VDO
  • Siemens No.: 5WK49515EBR
  • MCU: MC9S12XDP512
  • Mask: 0L15Y
  • FSV: 2.6.4
  • OSV: 3.3.0
  • Diag Index: 06A0
I'm specifically looking for a known-good original 512 KB internal flash from the same 5WK49515EBR / 61.35-9237047-01 / OSV 3.3.0 family. The VIN does not need to match because I'll retain my original EEPROM.

Any assistance or a donor flash from the same hardware/software family would be greatly appreciated. Thank you.
 
Upvote 0 Downvote

Post #4

Thanks for the thorough answers — this actually narrows it down a lot, and it points away from "I need a donor file" and toward "the BDM/flash write path is still not reliable."

The two symptoms you describe are the tell:

  • EEPROM (D-Flash side) reads/writes/verifies perfectly, but
  • P-Flash intermittently stalls at Bypass Security / Device is silent, and readbacks leave large regions still erased (0xFF).

That combination is almost never a bad donor image — it's a marginal BDM link, unstable target power, or the secured-flash unlock not completing. If the part were truly bricked it wouldn't ID or talk to EEPROM at all. So before flashing any donor:

  • Power: feed the CAS from a clean, stable bench supply, not just BDM parasitic power. Voltage sag during the mass-erase/program pulse is a classic cause of "Device is silent" mid-write.
  • BDM integrity: "sometimes reads, sometimes silent" = physical. Re-check BDMCLK, BDMDATA, RESET and GND continuity and length; keep wires short. A flaky RESET line will drop the part mid-sequence.
  • Security/erase: "Bypass Security" stalling means the unsecure/mass-erase step isn't finishing. On the XDP512 you generally need a full mass-erase (P-Flash and the secured sectors) to complete before a clean program — a partial/aborted erase leaves exactly the erased-region pattern you're seeing. Let it fully unsecure/erase, confirm blank check, then program, then full read-back and byte-compare.

Only once you can reliably read the full 512 KB back and verify does a donor flash make sense — and yes, your intact 95320 means a version-matched donor (same 9237047 / 5WK49515 family, OSV 3.3.0) will boot it.

To give you a precise next step, a couple of things would help:

  • Your exact XPROG version/build and which script/adapter you're selecting for the 0L15Y (there are separate "read" vs "read+unsecure" options that matter here).
  • A screenshot of the exact point where it stops at "Bypass Security" / "Device is silent".
  • Whether you're powering the CAS externally or purely from the programmer.

If the BDM link is solid and it still won't complete the secured erase, that's when I'd say the P-Flash controller took a hit during the original aborted write — but let's rule out the connection first, because everything you've described so far is recoverable.
 
Upvote 0 Downvote

Post #5

Thanks for the detailed analysis and recommendations. I appreciate you taking the time to review my case.

1. XPROG version/build and script used
  • Programmer: XPROG 5.55 (clone)
  • Device selected: MC9S12XDP512 – FLASH Secured – 0L15Y
  • Adapter: Standard XPROG MC9S12X adapter using direct BDM solder connections.
  • I did not use any alternative "read + unsecure" script—only the standard secured 0L15Y option available in XPROG.
2. Where it stops

The behavior is intermittent.
  • Initially, I could read both EEPROM and FLASH successfully.
  • During the original programming, XPROG failed with a communication error. After reflowing the BDM solder joints, I was able to communicate with the MCU again.
  • Now, the FLASH read sometimes hangs at "Bypass Security" (0%), and other times it proceeds but eventually reports "Device is silent."
  • EEPROM access remains reliable. I can still read, write, and verify the 95320 without errors.
3. Power source

The CAS was powered only from the XPROG adapter during all read/write operations. I did not use an external regulated bench power supply.

After reading your explanation, I realize this may have contributed to the instability during flash erase/programming, especially during the mass erase cycle.

Additional observations
  • I still have my original 512 KB internal flash backup and the original EEPROM.
  • The EEPROM has been restored and verified bit-for-bit against the original backup.
  • The EEPROM decodes correctly with the original VIN, ISN, mileage, and keys.
  • Every FLASH readback after programming differs from the source file.
  • In one comparison, the first 512 KB contained large regions left as 0xFF, while only selected sectors were programmed.
  • In the vehicle, the CAS is completely offline:
    • INPA reports IFH-0009 (No response from control unit).
    • The key no longer locks into the slot.
    • No Terminal 15.
    • The vehicle is effectively dead.
Based on your explanation, my next step will be to improve the programming setup by using a stable external bench power supply and rechecking every BDM connection before attempting another flash write.

If anyone has experience recovering a MC9S12XDP512 (0L15Y) after an interrupted XPROG write, or has any additional recommendations for XPROG 5.55 on this specific CAS3, I'd greatly appreciate your advice.

Thank you again for your help.
 
Upvote 0 Downvote

Post #6

There it is — item 3 is almost certainly your root cause. Powering the CAS only from the XPROG adapter is fine for EEPROM (tiny current, no high-voltage operations), but P-Flash mass-erase and programming on the XDP512 draw more and are timing-sensitive. Parasitic BDM power sags exactly during the erase/program pulse, which is why you get "Bypass Security" hanging at 0% and "Device is silent" mid-flash, while EEPROM stays rock solid.

Since you still have your original 512 KB flash backup, you may not even need a donor — try to reflash your own original once the power/BDM path is stable.

Do this in order before touching a donor file:

  • External power: feed the CAS its proper supply pin from a regulated bench supply (clean 12–13.8 V, a couple of amps headroom). Do not rely on adapter power for flash operations.
  • BDM link: keep BDMCLK/BDMDATA/RESET/GND short and solid. Your "sometimes reads, sometimes silent" is still partly physical — reflow and verify continuity on all four.
  • Full unsecure + mass-erase: with the secured 0L15Y option, let the unsecure/mass-erase complete fully and run a blank check before programming. The large erased (0xFF) regions in your readbacks mean the program step is aborting, not that the file is bad.
  • Program your original 512 KB backup, then do a full read-back and byte-compare against the file. Only trust it if it matches 100%.

If, after stable power and a verified full mass-erase, the P-Flash still won't accept a complete write and read back clean, then the die may have taken damage from the earlier aborted writes — that's the only scenario where a donor flash becomes the real fix rather than a workaround.

One thing to confirm: which pin are you feeding for external power, and does XPROG's blank check pass across the full 512 KB after a mass-erase? If blank check itself fails or is inconsistent, that's still the power/BDM path, not the flash contents.
 
Upvote 0 Downvote

Post #8

Heads up on that cas3_bkp_0L15Y.bin — it's not a clean full dump, so don't hand it to rockzt888r as a donor yet.

What the sampled bytes show:

  • The reset/interrupt vector table at the top and the code from ~0x40000 onward look like real XDP512 CAS3 firmware, so this is a genuine read of a live part.
  • But there are large stretches filled with 0x3F (the ?????? runs) — e.g. around 0x3FF40–0x3FFFF and 0x7FE80–0x7FFF0. That 3F fill is exactly the "read failed / bus silent" placeholder pattern, not valid flash content. A properly programmed sector reads as real code or 0xFF when erased, never solid 0x3F.
  • Overall entropy is only 5.46 bits/byte, which is on the low side and consistent with a partial read padded out with those 3F regions.

So this file has the same signature as the problem rockzt888r is fighting: intermittent BDM read dropping whole sectors. If it came off your own bench under stable power it'd be worth re-reading; if it's meant as a donor for him, it won't boot a CAS because those 3F blocks aren't real program data.

Whose part is this off — your own bench, or a candidate donor? And what's the source/read status: was it read in one clean pass with a verify, or is it one of the intermittent reads? If it's a donor, we need a full-length read that comes back with no 3F fill and passes a byte-for-byte re-read before it's usable.
 
Upvote 0 Downvote

Post #9

Thank you again for the detailed explanation. That makes a lot of sense, and I will definitely repeat the recovery using a regulated external bench power supply instead of relying solely on the XPROG adapter.

However, there is one concern that still makes me want to obtain a donor flash.

I'm not completely certain that my original 512 KB flash backup is actually good.

The initial programming failed due to a communication problem during the write process, and before that happened I had already experienced intermittent BDM communication. Although I have an original 512 KB backup that I made before the write, I can't say with 100% confidence that the backup itself wasn't affected by an unstable BDM connection or read errors.

Because of that uncertainty, I don't want to assume my original flash is a known-good reference. My plan is:
  1. Improve the hardware setup using a regulated external power supply and verify all BDM connections.
  2. Attempt to program my original 512 KB backup again and perform a complete byte-for-byte readback verification.
  3. At the same time, I'd still like to obtain a known-good donor flash from the same CAS family (61.35-9237047-01 / Siemens VDO 5WK49515EBR / MC9S12XDP512 0L15Y / OSV 3.3.0).
Having a verified donor flash would allow me to determine whether the problem is:
  • an unreliable original backup,
  • the programming process,
  • or the MCU itself.
So although I completely agree that stable power and BDM integrity should be addressed first, I'm still looking for a donor flash because I can't yet guarantee that my original backup is free from corruption.

If anyone has an original 512 KB internal flash from the same CAS3 hardware/software family and is willing to share it, I would sincerely appreciate the help. It would be extremely valuable as a known-good reference for comparison and recovery.

Thank you again to everyone who has taken the time to help troubleshoot this issue.
 
Upvote 0 Downvote

Post #10

Your plan is exactly right, and having a known-good donor as a reference is a sensible way to isolate backup vs. process vs. MCU. But before you go hunting for a donor, check your own original backup — you can likely settle the "is my backup good?" question yourself right now.

Same test I applied to the file Bin posted: open your original 512 KB backup in a hex editor and look for solid 0x3F fill runs. On this XDP512 family:

  • Valid flash reads back as real code/vector data or 0xFF in genuinely erased areas.
  • Large blocks of solid 0x3F = "bus silent / read failed" placeholder, i.e. a bad read, not real content.

If your backup is clean (real vectors at the top, code from ~0x40000, no 3F fill regions like the ones at 0x3FF40 and 0x7FE80 in Bin's file), then it's a good reference and you can trust it once your power/BDM is stable. If it shows those 3F runs, then yes — it was taken over a flaky link and you do need a donor.

On the donor itself: file structure aside, a matching donor for your case is P/N 61.35-9237047-01 / 5WK49515EBR / XDP512 0L15Y / OSV 3.3.0. Any donor offered here needs the same treatment before you trust it — a full-length read with no 3F fill that passes a byte-for-byte re-read, otherwise it'll brick the same way.

Can you post the same header/tail hex slice of your original 512 KB backup (offsets 0x0, ~0x3FF00 and ~0x7FE00)? That's enough to tell you immediately whether your own backup is usable and whether you even need to wait on a donor.
 
Upvote 0 Downvote

Post #11

Thank you for suggesting this test. I checked my original 512 KB backup exactly as you described.
Unfortunately, my backup does contain large regions filled with 0x3F, particularly around offsets 0x3FF00, 0x3FF40, and 0x7FE80.

The beginning of the file contains what appears to be valid code/data, but the repeated 0x3F fill patterns match what you described as a failed or incomplete BDM read rather than genuine flash contents. Because of that, I can no longer be confident that my original backup is a valid reference. It now appears that the backup itself may have been taken while the BDM communication was already unstable.

That reinforces my decision to continue looking for a known-good donor 512 KB flash from the same hardware/software family (BMW 61.35-9237047-01 / Siemens VDO 5WK49515EBR / MC9S12XDP512 0L15Y / OSV 3.3.0), while also improving my programming setup with a regulated external power supply and verifying the BDM connections.

Thank you again for pointing me toward checking the 0x3F fill regions—it was a very helpful diagnostic step.
 
Upvote 0 Downvote

Post #12

That settles it — your backup has the same 0x3F fill signature as Bin's file, so it was read over an unstable BDM link and can't be trusted as a reference. Good that you confirmed it now rather than after another failed write.

So your three-way plan is the right call: stable bench power + verified BDM, then a known-good donor to isolate backup vs. process vs. MCU. Two things to keep in mind while you wait on a donor:

  • Your car-specific data is safe regardless — VIN, ISN, mileage and keys all live in the 95320 EEPROM, which you've confirmed good bit-for-bit. The donor flash only supplies the program/OS, so a non-VIN-matched donor is fine as long as it's the same OSV 3.3.0 family.
  • Vet any donor with the exact 0x3F test before you flash it. Anyone can post a "good" dump that was actually read over a flaky link — Bin's file already proved that. A usable donor must show real vectors at the top, code from ~0x40000, no solid 0x3F fill runs, and it should pass a full-length byte-for-byte re-read on the person's own bench.

One practical note: I can't confirm from here whether anyone in the thread actually has a clean matching dump on the bench — that depends on a member stepping in. Since donor requests like this move faster with a bounty/trade offer, it's worth saying clearly in your request that you need 61.35-9237047-01 / 5WK49515EBR / XDP512 0L15Y / OSV 3.3.0, full 512 KB, verified no-3F read.

When you redo your own write with the regulated supply, post the header/tail slices of the fresh read-back and I'll help you confirm it came back clean.
 
Upvote 0 Downvote

Post #13

Thank you very much for taking the time to analyze my backup and for explaining the significance of the 0x3F fill pattern. That observation was something I hadn't considered, and it completely changed my confidence in the original backup.

After checking my original 512 KB flash, I found the same large 0x3F fill regions, so I agree that the backup itself can no longer be considered a reliable reference. It now appears that the original read may already have been affected by an unstable BDM connection before I even attempted to reprogram the CAS.

The good news is that my 95320 EEPROM has been verified multiple times. It is bit-for-bit identical to the original backup and decodes correctly with:
  • VIN: WBAUD71060P495192
  • Original ISN
  • Original mileage
  • Valid keys
That at least gives me confidence that the vehicle-specific data has been preserved.

I'll definitely follow your recommendations:
  1. Use a regulated external bench power supply instead of relying on XPROG power.
  2. Rework and verify all BDM connections before attempting any flash operation.
  3. Verify every flash by performing a complete readback and byte-for-byte comparison.
  4. Check any donor flash for 0x3F fill regions before considering it a valid reference.
I'm still looking for a verified, clean 512 KB internal flash from the following CAS:
  • BMW Part No.: 61.35-9237047-01
  • Manufacturer: Siemens VDO
  • Siemens No.: 5WK49515EBR
  • MCU: MC9S12XDP512 (0L15Y)
  • OSV: 3.3.0
  • FSV: 2.6.4
The VIN does not need to match. I'm only looking for a known-good, verified flash dump with no 0x3F fill regions that has been successfully read back and verified.

If anyone has this exact CAS module on the bench and is willing to share a verified 512 KB internal flash dump, I would be extremely grateful. I'm also happy to compensate for your time if needed.

Thank you again to everyone for the technical advice and for helping me narrow this down. It has been incredibly helpful.
 
Upvote 0 Downvote

Post #14

You've got the whole approach locked in now, and your EEPROM being verified good is the important safety net — everything car-specific is preserved, so this stays a recoverable job.

Where things stand: the donor itself now depends on a member with a matching part on the bench stepping in. I can't confirm from here whether anyone in the thread has a clean matching dump — that's on someone posting one. So the useful move is to make your request as easy to answer as possible:

  • Spec: 61.35-9237047-01 / 5WK49515EBR / XDP512 0L15Y / OSV 3.3.0 / FSV 2.6.4, full 512 KB
  • Explicitly ask for a verified no-3F read that passed a full-length byte-for-byte re-read on the donor's own bench
  • VIN match not required (car-specific data is in your 95320)

When someone offers a file, run the exact same 0x3F test on it before you trust it — real vectors at the top, code from ~0x40000, no solid 0x3F fill runs. If it shows any 3F blocks, it was read over a flaky link and will brick the same way, no matter how confidently it's labeled "good."

And when you redo your own write with the regulated supply and solid BDM, drop the header/tail slices (0x0, ~0x3FF00, ~0x7FE00) here — that'll immediately show whether your own re-read finally comes back clean, and you may not even need to wait on a donor at that point.
 
Upvote 0 Downvote
Activity
So far there's no one here