Z3M MSS50 DTC 155

[paulpbmw]

Highly recommend this UK bloke on YouTube with channel name Endtuning. He maybe a member of this forum, not sure.

He has done several MSS50 DME hardware diagnosis and repairs. I'm pretty sure he mentioned this very fault code in one of them. Cheers

https://youtu.be/FagjWiqLr20?is=q6qE6HFIIET949no

[Threadjaws]

Lookin to learn from the thread

[jos440]

DTC 155 can definitely be triggered by repeated low-voltage events, so before reflashing the DME I'd make sure the battery, charging system, grounds, and power supply to the DME are all healthy. If everything checks out, a WinKFP update is worth trying, but if the fault returns afterward, it's more likely a hardware issue inside the DME than corrupted software.

[MpowerE36]

Yep you're correct - FLASH memory is wiped at the block level so that every bit is a 1 (EEPROM is erasable at the byte level). At any time it is possible to write a 0 to a bit that was a 1, but you can't turn a 0 back into a 1 without wiping the whole segment.

So starting case is all 1s.

When adaptions, error memory, etc. needs to be written, it's written to the start of the block and a pointer stored in a special pointer list (this is what the OS then uses to know what types of records are where).

Next time the DME needs to make a change to that lot of data (e.g. adaptions), it invalidates the existing pointer, writes the new data further down the block (in a space that is currently all 1s) and writes the new pointer in the list.

It keeps doing this until it runs out of space in the block.

It then copies the valid data to RAM, wipes the entire block, and starts again.

So you're right, if the adaptions data was big enough to take up the whole block it would require an erase every drive cycle. In practice the amount of data to be stored is relatively small compared to the size of the whole block, so the wiping of the block is much less frequent.

It makes sense. Thank you

[karter16]

Interesting but from my understanding EEPROM can only be erased by sector (only way to flip a bit 0 to 1). So how is it possible to store different adaptations values at every powerlatch without erasing an entire EEPROM sector ? That is why I thought these values were stored in NVRAM in cpu but I am really not sure.

Yep you're correct - FLASH memory is wiped at the block level so that every bit is a 1 (EEPROM is erasable at the byte level). At any time it is possible to write a 0 to a bit that was a 1, but you can't turn a 0 back into a 1 without wiping the whole segment.

So starting case is all 1s.

When adaptions, error memory, etc. needs to be written, it's written to the start of the block and a pointer stored in a special pointer list (this is what the OS then uses to know what types of records are where).

Next time the DME needs to make a change to that lot of data (e.g. adaptions), it invalidates the existing pointer, writes the new data further down the block (in a space that is currently all 1s) and writes the new pointer in the list.

It keeps doing this until it runs out of space in the block.

It then copies the valid data to RAM, wipes the entire block, and starts again.

So you're right, if the adaptions data was big enough to take up the whole block it would require an erase every drive cycle. In practice the amount of data to be stored is relatively small compared to the size of the whole block, so the wiping of the block is much less frequent.

[MpowerE36]

Yup this was the right question to ask.

I just had a look at this (referencing MSS54 disassembly, however this part of the OS is very similar between the two). Dec 155 (Hex $9B) is triggered when the DME is unable to complete access of the EEPROM emulation block in FLASH successfully.

the MSS series use 'EEPROM' to store things like adaptions, DTCs, etc. except it's not actually EEPROM, it's FLASH with the OS providing an "emulation layer" of sorts that makes the FLASH feel like it's EEPROM to the calling function. Essentially every time new data is written to the 'EEPROM' the OS invalidates the old data, writes the new data into a clean section of the flash, and saves a new pointer to the new chunk of data. When it runs out of space in the block it copies the current data to RAM, erases the entire block and re-writes the current values at the beginning of the block.

The code is triggered when a failure to complete things like "retrieving adaptions from EEPROM" fails. OP if you share the details of the code then I can give you more specifics.

With this in mind I'd have thought it was more likely a problem with the flash memory than the CPU?

Interesting but from my understanding EEPROM can only be erased by sector (only way to flip a bit 0 to 1). So how is it possible to store different adaptations values at every powerlatch without erasing an entire EEPROM sector ? That is why I thought these values were stored in NVRAM in cpu but I am really not sure.

[karter16]

Ah so it's per driving cycle at best. Yeah I agree that shouldn't reach the rated limits particularly quickly then (though I do wonder if just existing 30+ years changes things)

yeah I think that that's more likely - probably just age wearing away at things, exposing flaws that are a bit vulnerable, etc.

[terra]

To be honest I don't know. There are 4 different types of data (as far as I can tell) that are written to this area. And certainly things like errors aren't being written every driving cycle, so I doubt it's particularly often.

Actually. Flipping it around. If we take # erase/write lifetime limit as ~100,000. And we make a very conservative assumption that the car is going through 2x driving cycles a day (e.g. a drive to work and a drive home). then even if every single driving cycle was triggering an erase/write cycle (which definitely won't be the case). then we'd be looking at 100,000/2 driving cycles a day = 50,000 days / 365 = ~140 years before wearing out the flash.

Ah so it's per driving cycle at best. Yeah I agree that shouldn't reach the rated limits particularly quickly then (though I do wonder if just existing 30+ years changes things)

[karter16]

Roughly how often would you say this happens? Enough that the cars are old enough to be running into the flash erase/write limits?

To be honest I don't know. There are 4 different types of data (as far as I can tell) that are written to this area. And certainly things like errors aren't being written every driving cycle, so I doubt it's particularly often.

Actually. Flipping it around. If we take # erase/write lifetime limit as ~100,000. And we make a very conservative assumption that the car is going through 2x driving cycles a day (e.g. a drive to work and a drive home). then even if every single driving cycle was triggering an erase/write cycle (which definitely won't be the case). then we'd be looking at 100,000/2 driving cycles a day = 50,000 days / 365 = ~140 years before wearing out the flash.

[terra]

Essentially every time new data is written to the 'EEPROM' the OS invalidates the old data, writes the new data into a clean section of the flash, and saves a new pointer to the new chunk of data. When it runs out of space in the block it copies the current data to RAM, erases the entire block and re-writes the current values at the beginning of the block.

Roughly how often would you say this happens? Enough that the cars are old enough to be running into the flash erase/write limits?

[karter16]

What is the actual routine this error gets stored? Does the CPU write values in RAM and the written data doesn't match the one(s) send to RAM?

Yup this was the right question to ask.

I just had a look at this (referencing MSS54 disassembly, however this part of the OS is very similar between the two). Dec 155 (Hex $9B) is triggered when the DME is unable to complete access of the EEPROM emulation block in FLASH successfully.

the MSS series use 'EEPROM' to store things like adaptions, DTCs, etc. except it's not actually EEPROM, it's FLASH with the OS providing an "emulation layer" of sorts that makes the FLASH feel like it's EEPROM to the calling function. Essentially every time new data is written to the 'EEPROM' the OS invalidates the old data, writes the new data into a clean section of the flash, and saves a new pointer to the new chunk of data. When it runs out of space in the block it copies the current data to RAM, erases the entire block and re-writes the current values at the beginning of the block.

The code is triggered when a failure to complete things like "retrieving adaptions from EEPROM" fails. OP if you share the details of the code then I can give you more specifics.

With this in mind I'd have thought it was more likely a problem with the flash memory than the CPU?

[Tomba]

What is the actual routine this error gets stored? Does the CPU write values in RAM and the written data doesn't match the one(s) send to RAM?

[MpowerE36]

I would try to replace the master cpu then if it doesn't work I would buy another one. Be careful with companies which "repair" this issue. They only disable dtc in the software which not solves the root cause of the problem.

Edit : according to karter16, it would rather due to a problem accessing the flash memory.

[isma_s54]

Thanks for your feedback.
So from your experience, do you think the DME/ECU needs to be completely replaced, or is there still a chance to repair it (CPU repair/rework)?




I’m trying to understand if it’s usually recoverable before looking for another MSS50 unit.

[MpowerE36]

Hi,

I've already had this problem and it is a hardware issue (cpu issue from my point of view).