MSS54HP CSL '0401' Community Patch binaries

[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.

[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]

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.

[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]

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]

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).

[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]

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!

[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!

[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]

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 😆

[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