MSS60 Research

[terra]

After flashing the shadow region of the injector processor my ECU is unbricked You just have to write the long 0x20410000 at 0x0 address (UC3FCFIG register).

As I showed in the #100 post, you can replace 0x300 by 0x0 or 0x100 if you don’t want the injector processor to lock anymore (apparently during SK writing).

It's cool to know that I can brick my dme as many times as I want and I could always get it back

Since your DME is unlocked now, in theory if you set ACCESS to 1, that should prevent it from being locked even if the censor bits are triggered. Haven't tested that personally.

[MpowerE36]

Which address needs to be patched to 0 or 100h?


Sent from my iPad using Tapatalk

For the 240E program :

Fullbinary from MSS6x flasher : 0xF555A (injection) & 0x362B4A (ignition)
External memory binary : 0x7555A (injection) & 0x62B4A (ignition)

Apparently there are also lock instructions for the ignition processor (seems not existing for program older than 240E).

[pshoey]

Great thanks.

Maybe it would be possible for us to add some code to a full dump to unlock the processor, set the shadow ram and set the access bit?


Sent from my iPad using Tapatalk

[terra]

Great thanks.

Maybe it would be possible for us to add some code to a full dump to unlock the processor, set the shadow ram and set the access bit?


Sent from my iPad using Tapatalk

While it's not theoretically impossible, it's not the easiest code to write, and would take a fair amount of debugging. You'd have to write something that can execute in RAM to run the uncensor routine, set whatever registers you need, and then restore at least the boot code. And this would more or less all have to be written in assembly.

[pshoey]

Agree it would take some effort and is not easy to debug but the code required is fairly small - and i bet could be written in C.


Sent from my iPad using Tapatalk

[MpowerE36]

Since your DME is unlocked now, in theory if you set ACCESS to 1, that should prevent it from being locked even if the censor bits are triggered. Haven't tested that personally.

I don't think it will work unless you also patch the program because the ACCESS bit is cleared before setting censor bits to 11.

[terra]

Ah I didn't pay that much attention to the subroutine. You're right, that wouldn't work then.

[julthefast]

Hopefully not too late to join the fun, I just picked up an M5 e60. I have a bunch of genuine commercial BDM tool (the usual suspects, ktag etc) and OBD that can read those DME.
Currently in the process of swapping an E92 DCT to replace the terrible SMG.

[boise567]

Do anyone knows what chips is for the oxygen sensor of DME mss65? I would like to replace that chip. Thanks

[binary420]

If I Bricked my e92 m3 mss60 engine ecu with a incomplete update, and i want to buy a replacement ecu,
how important is the part number when searching for a replacement MSS60 ECU module?

If I want to flash my original backup from my original ECU, will any MSS60 work or am I limited to a narrower selection, or does it for some reason need to match exactly?

Real oem says they are retrospectively interchangeable so I assume any MSS60 will work to replace and flash with my 2008 MSS60 backup flash / tune files

And is just flashing my full backup to the new device all that is needed to re-populate my original VIN / SK or are there any other steps I'm missing to get that accomplished?

[MpowerE36]

If you buy a new DME which is bdm locked (injection processor), you will not be able to make a clone of your bricked DME with your backup. Indeed, you will not be able to read and write in the flash memory of the injection processor (where are the VIN and the SK).

If you buy a new DME which is not bdm locked, you will be able to make a clone of your bricked DME with your backup. You can use a KTAG or FGTech for that.

Why don't you try to flash your backup in your bricked DME via bdm before buying a new DME ? Maybe the bdm access is not locked.

If it is locked, I can recover it for you but you will have to send me your DME.

[adrianj73]

Not sure if this is posted already, but may be of use. mss65, but very little difference to mss60. Ionic measurement moved onboard for mss60 with no external modules, EWS4, that's about it.

Note that non-populated CAN transceiver spot on the board (sheet 3, grid E4) for the "messcan" that uses TouCAN C. There's a "messcan" flag in the calibration area that switches the directionality of TouCAN C IIRC. This is used for high speed data logging in the engine test cell and in development cars as well as the real-time tuning via Can Calibration Protocol (CCP) using the INCA tools. There's a good program called ASAP2Demo that can connect to the mss6x if you have a well defined A2L for it. The CCP code in the DME copies the calibration table contents to RAM and CCP connects the external messCAN connected device/software to make real-time changes. I was never clear of the external tool then saved a file to be flashed back in after or if the CCP subroutine then copies the modified tables in RAM back to the flash area.

[Tomba]

Not sure if this is posted already, but may be of use. mss65, but very little difference to mss60. Ionic measurement moved onboard for mss60 with no external modules, EWS4, that's about it.

Note that non-populated CAN transceiver spot on the board (sheet 3, grid E4) for the "messcan" that uses TouCAN C. There's a "messcan" flag in the calibration area that switches the directionality of TouCAN C IIRC. This is used for high speed data logging in the engine test cell and in development cars as well as the real-time tuning via Can Calibration Protocol (CCP) using the INCA tools. There's a good program called ASAP2Demo that can connect to the mss6x if you have a well defined A2L for it. The CCP code in the DME copies the calibration table contents to RAM and CCP connects the external messCAN connected device/software to make real-time changes. I was never clear of the external tool then saved a file to be flashed back in after or if the CCP subroutine then copies the modified tables in RAM back to the flash area.

Main issue is getting a latest (241E) A2L for the ECU. Of course available but not public. All available I know off are likely pre-development which won't suit latest map layout, not to mention ram addresses for variables.
If available it would help a lot to map higher duration camshaft on that engine.

Very generous sharing such circuit diagram! Love it.

[terra]

Not sure if this is posted already, but may be of use. mss65, but very little difference to mss60. Ionic measurement moved onboard for mss60 with no external modules, EWS4, that's about it.

Note that non-populated CAN transceiver spot on the board (sheet 3, grid E4) for the "messcan" that uses TouCAN C. There's a "messcan" flag in the calibration area that switches the directionality of TouCAN C IIRC. This is used for high speed data logging in the engine test cell and in development cars as well as the real-time tuning via Can Calibration Protocol (CCP) using the INCA tools. There's a good program called ASAP2Demo that can connect to the mss6x if you have a well defined A2L for it. The CCP code in the DME copies the calibration table contents to RAM and CCP connects the external messCAN connected device/software to make real-time changes. I was never clear of the external tool then saved a file to be flashed back in after or if the CCP subroutine then copies the modified tables in RAM back to the flash area.

That's quite the resource there, much appreciated. That resistor to boot from external SRAM could be useful for recovering complete bricks.

A2Ls are hard to find for this DME. Only public one I'm aware of is from a prototype (which appears to be an old enough prototype to still be EWS3). Not sure how close the maps / config are to final.

[adrianj73]

That's quite the resource there, much appreciated. That resistor to boot from external SRAM could be useful for recovering complete bricks.

A2Ls are hard to find for this DME. Only public one I'm aware of is from a prototype (which appears to be an old enough prototype to still be EWS3). Not sure how close the maps / config are to final.

I believe that if you take a known good A2L and use it as a template, you can delete all the unnecessary declarations for measurements, characteristics, functions, etc that aren’t pertinent to you tuning goal. Then with some R/E you can identify hex locations for the ones you want to keep in whatever version you’re creating the A2L for, correct the map addresses, sizes, etc. and it should work. One of my goals this year getting back into it. Realistically, live tuning you probably need access to less than 20-30 calibration curves. Everything else would be primarily configuration changes that can be done by standard reflash.

have you verified your flasher can write a modified program? I want to move a few functions and customize them to test and relocate and enlarge a few KLs and KFs.