MSS54HP CSL '0401' Community Patch binaries

[terra]

I use my M3 as my daily driver for pretty much everything, and this weekend I'm taking the family on a longer trip. I plan to test after that gets out of the way — though I haven't given a single thought to what I'll do if it fails. I don't have a spare DME either.

Probably worth having a BDM tool and verifying it works if you can't get your hands on a spare DME

[karter16]

On a bit of a whim, I built a prototype tool that rewrites the bootloader (BL) over OBD.

Everything except the BL part has been tested — the BL itself is the one thing I'm still too scared to try.

Here's the outline of how it works.

As a starting point, my understanding is that the Am29F400BB is organised into sectors SA0–SA10 (SA = Sector Address).



The flashing we normally do over OBD goes through the BL in SA0, using the DS2 protocol. Which means rewriting the BL by the usual method was impossible over OBD — the BL can't erase itself.

So the tool takes this approach:

1. Place a loader in SA3, which DS2 can write freely.
2. Write the magic value 5A A5 56 C9 to 0xFFFC at the end of SA3, then power cycle. On reset the BL sees it, jumps to the loader in SA3, and the loader rewrites SA0.
3. Power cycle again — the new CSL BL comes up.
4. Write SA4–SA10 and SA3 to that CSL BL over DS2. ← same mechanism as the existing tools.
5. Once each for master and slave.

SA1 is kept as it is on the car, so you end up fully converted to CSL while retaining your own VIN and AIF.

I use my M3 as my daily driver for pretty much everything, and this weekend I'm taking the family on a longer trip. I plan to test after that gets out of the way — though I haven't given a single thought to what I'll do if it fails. I don't have a spare DME either.

Nice one. This is a similar approach to what my plan was. My thinking though for dev/testing was to jump to the loader in the parameter space (what you refer to as SA3) via DS2 call. If you write the manufacturer magic value to 0xFFFC then as you note you're locked in to it being called every time the DME boots. Jumping to it via DS2 call means if it fails then you can reboot the DME and try again (obviously only up until the point that you start writing the main bootloader). I think for the finished product using the magic value would be the way to go (e.g. once you have confidence in your loader) as it would eliminate any risks of the rewrite of the main bootloader partially failing, but for testing / debugging it would be better to start with running it via DS2 call so you don't have to BDM after every failure.

Like you I'm reluctant to have a go at this on my main DME - I think bmwfnatic is sending me one at some point so that I can try this (and other things) out more safely 😆

[mushitaro]

On a bit of a whim, I built a prototype tool that rewrites the bootloader (BL) over OBD.

Everything except the BL part has been tested — the BL itself is the one thing I'm still too scared to try.

Here's the outline of how it works.

As a starting point, my understanding is that the Am29F400BB is organised into sectors SA0–SA10 (SA = Sector Address).



The flashing we normally do over OBD goes through the BL in SA0, using the DS2 protocol. Which means rewriting the BL by the usual method was impossible over OBD — the BL can't erase itself.

So the tool takes this approach:

1. Place a loader in SA3, which DS2 can write freely.
2. Write the magic value 5A A5 56 C9 to 0xFFFC at the end of SA3, then power cycle. On reset the BL sees it, jumps to the loader in SA3, and the loader rewrites SA0.
3. Power cycle again — the new CSL BL comes up.
4. Write SA4–SA10 and SA3 to that CSL BL over DS2. ← same mechanism as the existing tools.
5. Once each for master and slave.

SA1 is kept as it is on the car, so you end up fully converted to CSL while retaining your own VIN and AIF.

I use my M3 as my daily driver for pretty much everything, and this weekend I'm taking the family on a longer trip. I plan to test after that gets out of the way — though I haven't given a single thought to what I'll do if it fails. I don't have a spare DME either.

[karter16]

Big thanks to ac427 who has tested, and confirmed working, the 32500 (CSL) boot loader version of Community Patch v1. The binaries for the 32500 bootloader are now available - linked in the original post.

Thanks ac427!

[karter16]

Mssflasher does have a minor quirk in that it doesn't fix the data checksums if patching from a full binary. But that shouldn't cause the issue reported above

Heh - that's a good trick - good to know this!

[terra]

(if they weren't MSSFlasher would have discovered this and auto-corrected them anyway).

Mssflasher does have a minor quirk in that it doesn't fix the data checksums if patching from a full binary. But that shouldn't cause the issue reported above

I guess one question would be if this is a converted DME? And if so any chance 29F400BT chips were used instead of 29F400BB -- that could cause similar issues.

[karter16]

Besides program CRC, I suspect there is data CRC, do you know which area it uses? I suspect my previous fails might be related to CRC errors. I'm currently buidling Python script to correct all files.

Gotcha - yes there is boot block CRC, program CRC and data CRC.

- Bootblock CRC you don't need to worry about as you're using one of the OE boot blocks.

- Program CRC's are dynamically located at the last non-0xFF location in the program block halves.

- Data CRC's are located at 0x3FFC and 0xBFFC (MSS54HP, using the standard slave-then-master single bin file format for DS2 programming).

There are also dynamically calculated versions of these for the DME to do it's own validation, as well as separate CRCs for CARB, etc, but these are not relevant for your purposes.

I can assure you that the Community Patch binaries have all CRC's correct (if they weren't MSSFlasher would have discovered this and auto-corrected them anyway).

[Tomba]

So you started with a DME that has the 32300 bootloader and then used OBD to flash the community patch program and it failed when it got to the slave half is that right?

Yes and Yes. If it was exactly half way I don't know. But for sure failed.

Then when you built the BDM files you used the reads off your 32300 working read and put the program and data sections from community patch into the BDM files and then BDM'd those?

I did flash back the originals ones back by BDM which brought back the ECU to life.
Then used a real 32500 BL and this one succeeded.
Didn't use the patch files at this point.

Besides program CRC, I suspect there is data CRC, do you know which area it uses? I suspect my previous fails might be related to CRC errors. I'm currently buidling Python script to correct all files.

[karter16]

- Flashed back original files with BDM and got the ECU working again.
- Tried to flash the patch for 32300 ECU with 32300 BL, but it failed on writing the slave memories.
- created 2 files from the larger patch file to flash it by BDM. Partly responds but error code reading and live data is not responding well. Can't write AIF @ address 0x7504.
- Also tried to flash it with Kim F's Siemens MSXX flasher but same result.
- Really don't know what I am doing wrong.....

- Got a 32300 HW ECU and I would assume the patch file above would be suitable for this.

So you started with a DME that has the 32300 bootloader and then used OBD to flash the community patch program and it failed when it got to the slave half is that right?

Then when you built the BDM files you used the reads off your 32300 working read and put the program and data sections from community patch into the BDM files and then BDM'd those?


Sent from my iPhone using Tapatalk

[Tomba]

Are you writing the files via BDM?

Could it be a checksum issue?

Maybe the files would write ok across OBD?

Just got a file from YulCmb (Yulien) which works. So will work on that one further (32500 BL).
I do suspect checksumm issue altough the full bin from here loaded in MSSFlasher says checksum is OK.

[ac427]

- Flashed back original files with BDM and got the ECU working again.
- Tried to flash the patch for 32300 ECU with 32300 BL, but it failed on writing the slave memories.
- created 2 files from the larger patch file to flash it by BDM. Partly responds but error code reading and live data is not responding well. Can't write AIF @ address 0x7504.
- Really don't know what I am doing wrong.....

Are you writing the files via BDM?

Could it be a checksum issue?

Maybe the files would write ok across OBD?

[Tomba]

I will BDM flash it back and give it another try. Always seems the case when I want to do a quick flash for someone I end up soldering BDM headers and or EEPROMs...

- Flashed back original files with BDM and got the ECU working again.
- Tried to flash the patch for 32300 ECU with 32300 BL, but it failed on writing the slave memories.
- created 2 files from the larger patch file to flash it by BDM. Partly responds but error code reading and live data is not responding well. Can't write AIF @ address 0x7504.
- Also tried to flash it with Kim F's Siemens MSXX flasher but same result.
- Really don't know what I am doing wrong.....

- Got a 32300 HW ECU and I would assume the patch file above would be suitable for this.

[karter16]

Might be time to work on my own flasher

I'm actually working on this at the moment - see here: https://nam3forum.com/forums/forum/m...130#post353130

One of its main features is comprehensive logging so that if any odd behaviours ever happen I can do RCA.

[Tomba]

I have found this seems to happen with MSSflasher sporadically. Never could find a root cause. From what I recall, a large chunk of the flash ends up being 0'd out

Might be time to work on my own flasher. Seems like the ediabaslib bug that caused issues the last time I attempted this has been fixed

I will BDM flash it back and give it another try. Always seems the case when I want to do a quick flash for someone I end up soldering BDM headers and or EEPROMs...


So your expecting the data send to the interface to be OK but handled differently time to time inside the interface? Or could the cable be OK and the program has some kind of error in it? I don't know if the messages send over USB have checksum correction and if the cable would react on incorrect checksum.
I currently understand that ediabas library flashed interface handles the sizes of the packages send by the PC in correct way, where this could not be the case in some interfaces and resulting in errors. Do you have examples on how the data is send over USB FTDI? There seems to be no official documentation.

I added the PowerTrain CAN wires for sniffing to my E46 OBD connector and while reading out engine data over K-Line with Tool32/INPA I could see the instrument cluster going off due to missing CAN messages. I would expect that the messages send from USB to interface are internally handled by the interface for both k-line and CAN? Normally one or the other is present which make sense.

Your own interface seems like a good idea, I was thinking of this a month ago to add support for L-line and K line ECUs (Motronic 1.x - 3.x). I normally use ICOM for old ECUs, but the ediabas library used for VS was only serial. I now know the LAN/IP is also present in ediabas library and I could create by own program for reading old motronics.
I don't want to hijack this thread for it, maybe a discussion in a new thread?

[terra]

Thanks for uploading this.
I got myself in a difficult situation yesterday.
I have a 2113 2300 2501 xxxx MSS54HP ECU which I wanted to flash with the patch above (With MSSFlasher). Everything went well until a certain moment the writing was not OK.
ECU responds to [aif_lesen] and ID but can't rewrite it again. It first IDs and then it receive a bad responds 1204b0a6.
Looked up forums and found out to boot mode it. Grounding pin #37 of each (master & slave) flash memory to ground during start up (30+ and 15+) for at least 5seconds. Then tried to write the original back but it remains coming with error 1204b0a6.
I do have a BDM device, but was hoping someone knows what went wrong and to prevent this.

K+DCAN cable from bimmergeeks, latency @1ms. Bench flashing harness @ solid 13.5V. MSSFlasher is at version 1.00.4 from memory (not 100% sure).

I have found this seems to happen with MSSflasher sporadically. Never could find a root cause. From what I recall, a large chunk of the flash ends up being 0'd out

Might be time to work on my own flasher. Seems like the ediabaslib bug that caused issues the last time I attempted this has been fixed