VOLVO V50 2010 CEM IMMO KEY From CEM-TYPE3-MC9S12XDT256 EEPROM/FLASH.bin

• What do you actually need the PIN/KEY for — adding/programming a key, or CEM↔ECU (SID803) resync after a swap?
• Which chip is which: you said chip 10 is the "stored data" — is chip 10 the CEM you're keeping and chip 11 a donor/used CEM, or are both from the same car?
• Confirm these FLASH files are full 256K reads off the MCU (they are 256K here, good) and the EEPROMs are the external 95-series, not partial.
• Engine ECU type on this car (SID803 / SID807 / ME9?) — that decides whether a sync tool even applies.

Gemini said:

Your read looks sane at first glance — the FLASH chip 10 dump clearly contains the correct VIN YV1MW7551A2560339 plus the PJB part numbers (@(#)PJB_A 31343159 AA and @(#)PJB_A 31343848 AA), and the EEPROMs (chip 10 = 4K with real data, chip 11 = 4K) are populated rather than blank, so it seems both modules were dumped properly.

That said, I can't read a PIN out of these bytes for you. On the 2010 P1 CEM the immo/PIN data isn't stored as plain ASCII in the EEPROM — it's derived, and it needs a dedicated Volvo P1 CEM calculator that understands the CEM-TYPE3 / MC9S12XDT256 layout. The S40/V50/C30 CEM & SID803 Synchronization Utility in Resources (#132) is aimed at these cars, but it's built around the SID803 sync workflow, not a pure "type your PIN here" reader, so I'd only trust it if the tool's own notes cover MY2010 CEM-TYPE3.

To point you at the right thing, a couple of specifics:

• What do you actually need the PIN/KEY for — adding/programming a key, or CEM↔ECU (SID803) resync after a swap?
• Which chip is which: you said chip 10 is the "stored data" — is chip 10 the CEM you're keeping and chip 11 a donor/used CEM, or are both from the same car?
• Confirm these FLASH files are full 256K reads off the MCU (they are 256K here, good) and the EEPROMs are the external 95-series, not partial.
• Engine ECU type on this car (SID803 / SID807 / ME9?) — that decides whether a sync tool even applies.

With that I can tell you whether the #132 utility fits or whether you need a different P1 PIN approach.

Click to expand...

Franks_int said:

Yes these are from the same car.

EPROM & FLASH from CEM - CHIPS , AUTEL IM608 PRO 2 is usedto extr...

Click to expand...

• When VDASH asks for the "CEM IMMO PIN / Key" for the ECM-C326 job — is it asking for a short PSK (a few digits/bytes) or a full CEM key file? That changes what you feed it.
• Did the Autel show any PIN/PSK value at all during the read, or did it only give you the bin dumps?
• Which of your two 4K EEPROMs is the actual immo-carrying one — chip 10 (the one with live data) is the likely candidate, but confirm what the Autel labelled them.

Gemini said:

Right, that clears up the setup. A couple of things worth separating here:

The PIN isn't sitting readable in those dumps. On the P1 CEM-TYPE3 the immo secret (PSK) isn't stored as plain ASCII — none of the printable strings in your chip 10 EEPROM are the PIN. It has to be calculated from the CEM data by a tool that knows the CEM-TYPE3 / MC9S12XDT256 layout. So dumping the chips was the right move, but you still need something to turn the dump into the PIN.

Easiest route with what you already own: the Autel IM608 Pro 2 normally spits out the CEM PSK/PIN itself during its Volvo IMMO routine. Go into the IMMO/Key Learning menu for the V50, run the CEM read / "read immo data" or "read password/PIN" step — on P1 Volvos the Autel typically displays the PSK there rather than making you extract it from a raw bin afterwards. If you have that number, that's the value VDASH is asking for.

To make sure we're chasing the right thing:

• When VDASH asks for the "CEM IMMO PIN / Key" for the ECM-C326 job — is it asking for a short PSK (a few digits/bytes) or a full CEM key file? That changes what you feed it.
• Did the Autel show any PIN/PSK value at all during the read, or did it only give you the bin dumps?
• Which of your two 4K EEPROMs is the actual immo-carrying one — chip 10 (the one with live data) is the likely candidate, but confirm what the Autel labelled them.

If the Autel didn't display a PIN, then it's a calculator job on the chip 10 dump specifically — tell me and we'll look at what P1 CEM PIN tool fits. Just so I'm clear: is C326 the fault you're clearing, or is it appearing because the ECM/CEM immo link is broken after work was done on the car?

Click to expand...

Franks_int said:

-Autel did not give me any input on the calculation, it only tell me if it's OK or not.
-I don't have the Autel device for hand at the moment, i foun out the Vdash software could help me to fix the IMMO sync error between CEM -ECM, since when the autel checked with the modules nor ''Error'' apears, because it's the same PIN found in the modules, but the error it self is the sync between the modules. - If you check with the Autel all looks good.
-I have one moe file extracetd with Autel- this is from the menue called secure data. but i think it's the same as the'' chip 10, EEPROM file''

-V dash tell me to add CEM IMMO PIN in this format
'' The valid format is HEX (e.g. 000004CF00) or DEC (e.g. 236794083445).''
VDash can decode some PINS-For me

Click to expand...

Franks_int said:

-Autel did not give me any input on the calculation, it only tell me if it's OK or not.
-I don't ha...

Click to expand...

• The two 4K files are the same content. The "secure data chip 10" export and the earlier "EEPROM chip 10" match byte-for-byte in every region I can see (same header at 0x00, same block at 0x810, same strings). So that secure-data menu just re-dumped the same EEPROM — it isn't a second, different source.
• I can't hand-calculate that PIN from these bytes. The value VDASH wants in that 000004CF00 / DEC form is the derived PSK, and on CEM-TYPE3 it isn't sitting readable in the 4K EEPROM. Nothing in this dump is the PIN in plain form, so me eyeballing the hex won't produce it.

• In VDASH, look for the CEM PIN / PSK extraction (not the manual "enter PIN" field) and point it at the 256K FLASH dump you took with the Autel, or flash+EEPROM together if it offers that.
• Tell me exactly what VDASH's PIN-extract screen asks you to load — full flash, EEPROM, or both — and I'll tell you which of your Autel files matches.
• Confirm the FLASH file is a clean full 256K read (it was 256K earlier, good) and hasn't been trimmed.

• The format VDASH wants (000004CF00 / 236794083445) is the 5-byte PSK. I can't pull that value out of the bytes you posted — this "secure data" 4K dump shows structured log/counter-type entries, not a plaintext PSK, so there's nothing readable to just copy out.
• VDASH's own PIN decode function is the right path since you said it can decode some for you — but it normally wants the full CEM EEPROM dump, not a partial "secure data" export. A 4K slice that Autel labelled "secure data" may not be the whole EEPROM VDASH expects.

• Is your "chip 10 EEPROM" a full external 95-series dump, and how big is it (this secure-data one is only 4K)?
• When you load the CEM EEPROM into VDASH's PIN decoder, what does it say — does it output a PSK, or reject the file?

Gemini said:

Yeah, that actually fits the picture — a stuck door micro-switch keeping the CAN network awake while the battery collapses is a classic P1 trigger for a CEM↔ECM immo desync. The modules individually still hold the same PIN (which is why Autel reports "OK"), but the sync/counter state between CEM and ECM got corrupted during that brownout. That's exactly the C326 situation VDASH is trying to repair, so you're on the right track using VDASH for the resync rather than a full key job.

On the PIN itself, two things:

• The format VDASH wants (000004CF00 / 236794083445) is the 5-byte PSK. I can't pull that value out of the bytes you posted — this "secure data" 4K dump shows structured log/counter-type entries, not a plaintext PSK, so there's nothing readable to just copy out.
• VDASH's own PIN decode function is the right path since you said it can decode some for you — but it normally wants the full CEM EEPROM dump, not a partial "secure data" export. A 4K slice that Autel labelled "secure data" may not be the whole EEPROM VDASH expects.

So before anything else: feed VDASH the complete CEM EEPROM (your chip 10 EEPROM read), point it at its "decode PIN from CEM" function, and see what it returns.

To make sure we match files correctly:

• Is your "chip 10 EEPROM" a full external 95-series dump, and how big is it (this secure-data one is only 4K)?
• When you load the CEM EEPROM into VDASH's PIN decoder, what does it say — does it output a PSK, or reject the file?

Click to expand...

Franks_int said:

Vdash dont show me anything. the only thing i know
it should be possible to find my CEM IMMO pIN wit...

Click to expand...

• The full 256K CEM FLASH dump from the Autel (the .bin should be exactly 262144 bytes)
• The external CEM EEPROM read — what size is it? If it's only this 4K, that's the internal MCU EEPROM, not the external immo chip
• The exact ECM type on this car (SID803 / SID807 / ME9?) — that decides whether the #132 sync path applies