Let's Talk E92 Flash,EEPROM and Slave

[tpepmeie]

Thanks to Ironduke, I was able to read full flash for a couple of E92, 2-byte. One is an OEM replacement straight out of the box.

I note there is (obviously) no VIN, mileage or programming date in the EEPROM area. I expected that.
There is no slave OS, or slave cal data anywhere in the EEPROM sections (0x10000 and 0x20000). On other files, I have seen several references to the slave os, and calibration part numbers in the EEPROM. But nothing in this OEM replacement. All the other segments of the flash are programmed. Guessing the dealer would reflash the whole thing with SPS according to the VIN. But how does the EEPROM get written with the slave data?

On that unit though, a cheap scan tool DOES show the part numbers loaded for both of these segments (12625016 and 12624281). Is it correct that these are both stored on the slave chip elsewhere in the ECM (not the main flash)? Scan tools must be able to read, at least the p/ns, directly from the slave controller, then?

Does a full SPS also flash the slave chip?
Thanks,
Todd
[Original Post edited based on my learning more about the flash memory locations]

[Tazzi]

The slave OS/Calibrations are usually on a separate processor, which is the "slave" to the master CPU

The master and slave communicate via SPI (typically). Update routines can vary between ECUs, but sometimes a custom kernel is uploaded to the slave to allow updating it. Othertimes the slave does not require any custom code, and already has the code built into its boot code to allow being updated.

GMs SPS does flash the slave chips.

[tpepmeie]

I updated the original post, as I've learned more about the various memory addresses. Still not sure how/when the usual slave data gets stored to EEPROM on the E92 (or E38 for that matter).

[Tazzi]

The emulated eeprom does not get the slave OS/cals written to it.

The slave operating system and calibrations are written to the separate slave processor on the circuit board.
For example, an E38 has a MC9S12 slave processor, whereas the main processor is a MPC562.

[tpepmeie]

Tazzi, you’re right. I didn’t mean to say the whole slave os and slave cal gets written. Rather, it looks like the part number identification for both definitely gets written to EEPROM areas. A few places too it looks like. I wonder what command causes that p/n write to happen?

[tpepmeie]

Something as simple as a power cycle and reading/clearing DTCs (even though none were present), seems to have caused the EEPROM area to get written including the p/n identifier from the slave OS and cal, I discovered tonight. This is all on a bench, not in a vehicle.

[tpepmeie]

Using SPS to do a clean re-program of a used E92a. VIN won't change, and the SPS program hangs and fails during the second write. Before attempting to program, got the warning that the VIN in the device is different than the selected vehicle VIN. Three options, accept, override, or cancel. I selected Override.

First programming pass completes. Then it starts a second programming pass and hangs up with 4:37 or so remaining in that pass. What's interesting is that it appears all of the segments, including OS, cal and slave got written with the correct data on the first pass. When I read it on various scan tools, and HPT all the segments look fine. But the VIN is still the original VIN.

Tried clearing codes, waiting, power cycling. Still hangs up and won't complete the second SPS pass, and therefore doesn't change the VIN.

[tpepmeie]

Update- I used a vin change utility and it changed. From there, the SPS flash completed normally.

[Tazzi]

Update- I used a vin change utility and it changed. From there, the SPS flash completed normally.

It will now have mismatch security code in it, which makes the ECU basically useless unless disabling the security in the tune.

[tpepmeie]

Security code, as in Immobilizer or VATS code, or whatever it's called?