[rjahl]

I've picked up this instruction from another forum on how to recycle a used MSV70

read the flash and make the following modifications ; Address 4020 to 7FFF and 40000 to 7FFFF FILL FF


I've never tried it, But if you already have a back up copy of the flash, it would be an easy test. You will certainly need to use Winfkp to flash a new 0pa and 0da file afterward and recode

[hassmaschine]

Yeah, I would try to flash your entire EEPROM. You can blank out the AIF area (not sure why the parameter section would matter?) but that's not going to change anything in the EEPROM and it isn't really "resetting it" back to factory.

Mileage is stored there, along with some other vehicle specific things (VIN of course).

BTW if that software is really 049PP901S, it's in need of an update. The current version is 049PP921S.

[rjahl]

Originally Posted by hassmaschine

Yeah, I would try to flash your entire EEPROM. You can blank out the AIF area (not sure why the parameter section would matter?) but that's not going to change anything in the EEPROM and it isn't really "resetting it" back to factory.

Mileage is stored there, along with some other vehicle specific things (VIN of course).

BTW if that software is really 049PP901S, it's in need of an update. The current version is 049PP921S.

I agree, I'm not sure dumping the parameter section is really going to do anything unless this somehow initiates a routine to rebuild the EEPROM data. As I've never done it, I could only pass on the quote. It seems to me that clearing the UIF area would be more important.

He can try both methods and see what works, he might need to do both. Clear the UIF and wipe the EEPROM.

If all else fails, swapping EEPROMs took my friend about 5 minutes.

[drc38]

Originally Posted by rjahl

I agree, I'm not sure dumping the parameter section is really going to do anything unless this somehow initiates a routine to rebuild the EEPROM data. As I've never done it, I could only pass on the quote. It seems to me that clearing the UIF area would be more important.

He can try both methods and see what works, he might need to do both. Clear the UIF and wipe the EEPROM.

If all else fails, swapping EEPROMs took my friend about 5 minutes.

Where is the serial eeprom on the board, I couldn't spot an 8 pin device with labelling to suggest it was an eeprom?

[drc38]

Originally Posted by hassmaschine

Yeah, I would try to flash your entire EEPROM. You can blank out the AIF area (not sure why the parameter section would matter?) but that's not going to change anything in the EEPROM and it isn't really "resetting it" back to factory.

Mileage is stored there, along with some other vehicle specific things (VIN of course).

BTW if that software is really 049PP901S, it's in need of an update. The current version is 049PP921S.

From the snip it is not showing the post winkfp software version which is 049PP921S. The 901S is what the replacement dme came with.

When you say flash entire eeprom, I am flashing each section separately ie serial eeprom, mpc and flash. Then run checksum check. Will try blanking the sections and see what happens.

If a dme can be cloned by copying its 4k eeprom as well as flash and mpc, and I have the flash and mpc originals, and most of the eeprom is written to or over by winkfp/ncsexpert I would have thought there is perhaps some form of checksum that remains static that could be looked up in the cas?

My logic in comparing to another dme was that bytes that are the same can be ignored as they represent common structure. Then looking at eeprom before and after winkfp/recode anything that has changed is also not likely. May be an over simplification if some form of rolling code is stored however.

[drc38]

One other thing that may be useful, when the dme throws the error it reports a km reading of 120,992km whereas my odo is around 158k. It doesn't appear to be stored as a straight hex conversion though.

[hassmaschine]

I have the conversion factor somewhere.

[Terraphantm]

Originally Posted by drc38

Where is the serial eeprom on the board, I couldn't spot an 8 pin device with labelling to suggest it was an eeprom?

IIRC the one on the top right of this picture is the eeprom

[drc38]

Originally Posted by Terraphantm

IIRC the one on the top right of this picture is the eeprom

Cheers I was busy looking on the underside, looks like it is a ST 95320 on my board.

[drc38]

Originally Posted by rjahl

I've picked up this instruction from another forum on how to recycle a used MSV70

read the flash and make the following modifications ; Address 4020 to 7FFF and 40000 to 7FFFF FILL FF


I've never tried it, But if you already have a back up copy of the flash, it would be an easy test. You will certainly need to use Winfkp to flash a new 0pa and 0da file afterward and recode

I found a pdf online on how the EWS works with the DME, my take on it is the only way to viginize a DME is to clear the rolling code table such that a new table gets written from the CAS. Alternatively, find the table in the CAS and copy it to the eeprom. My suspicion is the table starts at 04 offset and contains 3 rows of 12 bytes with D2 D2 at the end of the first two rows and 2D 2D at the end of the third. If anyone has a copy of their CAS bin it should be straightforward to check.

[rjahl]

Originally Posted by drc38

I found a pdf online on how the EWS works with the DME, my take on it is the only way to viginize a DME is to clear the rolling code table such that a new table gets written from the CAS. Alternatively, find the table in the CAS and copy it to the eeprom. My suspicion is the table starts at 04 offset and contains 3 rows of 12 bytes with D2 D2 at the end of the first two rows and 2D 2D at the end of the third. If anyone has a copy of their CAS bin it should be straightforward to check.

Have you tried to clear the UIF section of the flash yet? Afterwords your WinFKP write must have the write UIF checkbox ticked.

Perhaps you can post your files on a Dropbox or similar.

[hassmaschine]

Originally Posted by drc38

I found a pdf online on how the EWS works with the DME, my take on it is the only way to viginize a DME is to clear the rolling code table such that a new table gets written from the CAS. Alternatively, find the table in the CAS and copy it to the eeprom. My suspicion is the table starts at 04 offset and contains 3 rows of 12 bytes with D2 D2 at the end of the first two rows and 2D 2D at the end of the third. If anyone has a copy of their CAS bin it should be straightforward to check.

the rolling code table is changed when you re-sync the CAS. MSV70 is EWS3; all it needs is the ISN which you've already copied over (it's in the AIF section).

The problem is the data in your EEPROM doesn't match your car. You need to change it - probably the power class is wrong and the VIN and mileage also. You shouldn't need to do anything with your main BIN.

[drc38]

Originally Posted by rjahl

I've picked up this instruction from another forum on how to recycle a used MSV70

read the flash and make the following modifications ; Address 4020 to 7FFF and 40000 to 7FFFF FILL FF


I've never tried it, But if you already have a back up copy of the flash, it would be an easy test. You will certainly need to use Winfkp to flash a new 0pa and 0da file afterward and recode

I am back up and running, thank you all for the help!!

As per the above I filled the following ranges with FF, wrote flash via BDM (although I assume it could also have been done via OBD), Winkfp, NCSExpert, CAS alignment, Clear errors, insert fuel pump fuse a viola... a working dme.

Looking at the resulting flash file, I suspect only the 4020-7FFF clear is needed. And perhaps only from 43C8 as the BDM tool cannot identify the dme family once the procedure above is carried out.

Once again appreciate all the help... and now back to looking at mapping changes.

If you want any of the files give me a PM and I'll send them through.

[stevethresh]

Any chance you could document how it would be done through the OBD port please? I’ve had to clone my DME and now have a car that turns over but won’t start with the 2f47 error.