MSS54HP CSL '0401' Community Patch binaries

[Tomba]

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

[BMWfanz]

Guys! I have swapped MSS54HP in E30, currently have a problem with reading error codes, maybe you can help me to sort it out( Bin attached

[0-60motorsports]

Some random thoughts from me:

• If/when we have a free tool that allows for writing the boot loader over OBDII then there are probably limited reasons why anyone doing a CSL conversion would want to remain on the M3 boot loader. At that point it might be worth introducing a custom boot loader which would give the flexibility to do things like disabling the writing of the AIF counter bytes.
• I've been thinking a little bit about the versioning discussion. At the moment (support for M3 boot loader aside) community patch prog binary is backward compatible with standard 0401 tune binary and community patch tune binary is backward compatible with standard 0401 prog. I'm inclined to think that so long as that remains true it might be less hassle for everyone to stay with the 0401 version number - means people can bring their current 0401 tune to community patch prog binary without having to reflect a change in version numbers.
• When I get a chance I'll publish details of the exact memory locations and code locations that Community Patch uses - doesn't affect the average user but important information for anyone who might also be using other tools to modify their binary.

I'm also working through building out the custom CANbus messages into an upcoming version of community patch. Looking like the key features will be:

• Ability to configure contents of 0-3 custom CAN messages.
• Ability to make up to 16 bytes of Slave-CPU-only variables available to the custom CAN messages.
• Publication of a list of all known RAM variables with addresses to inform ^.
• Feature will be disabled by default so no impact to existing tune files.

All you guys working on all of this are a blessing to the community. Thank you.

[karter16]

Some random thoughts from me:

• If/when we have a free tool that allows for writing the boot loader over OBDII then there are probably limited reasons why anyone doing a CSL conversion would want to remain on the M3 boot loader. At that point it might be worth introducing a custom boot loader which would give the flexibility to do things like disabling the writing of the AIF counter bytes.
• I've been thinking a little bit about the versioning discussion. At the moment (support for M3 boot loader aside) community patch prog binary is backward compatible with standard 0401 tune binary and community patch tune binary is backward compatible with standard 0401 prog. I'm inclined to think that so long as that remains true it might be less hassle for everyone to stay with the 0401 version number - means people can bring their current 0401 tune to community patch prog binary without having to reflect a change in version numbers.
• When I get a chance I'll publish details of the exact memory locations and code locations that Community Patch uses - doesn't affect the average user but important information for anyone who might also be using other tools to modify their binary.

I'm also working through building out the custom CANbus messages into an upcoming version of community patch. Looking like the key features will be:

• Ability to configure contents of 0-3 custom CAN messages.
• Ability to make up to 16 bytes of Slave-CPU-only variables available to the custom CAN messages.
• Publication of a list of all known RAM variables with addresses to inform ^.
• Feature will be disabled by default so no impact to existing tune files.

[karter16]

Coming from a patchlist approach on MS43, I have to admit, that fixed versions (MS43X001,2...) with patches included and only calibation data changeable is the better way.

It prevents a lot of hassle, because TunerPro has no validation feature. If the user loads a wrong binary, he can revert+patch and have a "valid" file with garbage code inside.

Not sure how MSS54 and Inpa plays along, but i think its fine as long as you don't alter the hardware id.

Thanks that's good to know, I was planning at this stage to stick with set program versions so that's good to have your feedback that that's probably the way to go as well.

Good point re the version numbering. When I get some time I will give this a go (change it) and test with INPA.

[sda2]

Coming from a patchlist approach on MS43, I have to admit, that fixed versions (MS43X001,2...) with patches included and only calibation data changeable is the better way.

It prevents a lot of hassle, because TunerPro has no validation feature. If the user loads a wrong binary, he can revert+patch and have a "valid" file with garbage code inside.

Not sure how MSS54 and Inpa plays along, but i think its fine as long as you don't alter the hardware id.

[karter16]

I wonder if it's worth renaming the binaries to 0501 or 0402 or something 🤔

I did vaguely wonder about that a couple of months ago. What I wasn't sure about was whether there was a risk of any issues for anyone dealing with BMW (unrecognised version number and all that)? At this point, aside from the M3 boot loader support the program binaries are backward compatible with standard 0401 tune files, but if other things are added in time that might not always be the case, so a separate version number would be safer in that regard I guess.

[karter16]

Ah that would be awesome - I'll flick it over to you now in case you can.

[terra]

My M3's currently in storage, but with it warming up I could probably drop by the car in the coming days and test the CSL bootloader binary. Might be a good time to see if MSSFlasher works properly on windows for ARM too

I wonder if it's worth renaming the binaries to 0501 or 0402 or something 🤔

[karter16]

This is awesome, thanks for sharing!

Have you considered adding these to your GitHub repo? Version control would be much easier that way.

Yep I will do - I've got some wider revamping to do of the repo and will move it across there once I've got that sorted and update the links :-)

[heinzboehmer]

This is awesome, thanks for sharing!

Have you considered adding these to your GitHub repo? Version control would be much easier that way.

[karter16]

What is this?
'Community Patch' consists of the stock CSL '0401' program and tune binaries, with a collection of core modifications that have been made to serve the needs of the community. The intent of Community Patch is to consolidate the knowledge that has been gained into a single pair of binaries that can be used as the foundation of CSL conversions. I say "pair of binaries" because I intend to maintain Community Patch for both those running 2500 CSL boot loader and the 2300 M3 boot loader.

Version 1 of Community Patch includes a few core improvements/consolidations that I think will be useful to the community as a whole. The goal would be to maintain future versions of Community Patch where those additions would benefit the community at large.


Disclaimer
Modification of your DME's code is inherently risky. Use of any modified program or binary is at your own risk. The binaries provided here are intended for off-road uses only. Every reasonable effort has been taken to ensure that the changes made are sound and free of error, however the author takes no responsibility for any issues and/or negative outcomes arising from the use of these binaries.

It should be noted that the nature of the changes made do not interact with or impact the safety mechanisms built into the OE software in any way. If you are concerned or have any specific questions I am happy to provide more information.


Acknowledgements
This is the latest iteration of years of effort from many in the community. In particular I believe it was Paffy who figured out the initial trick to get the CSL software working with the M3 boot loader, and then Terra who figured out the fix for reading codes. I'm honoured to be able to add my own contributions to the work of legends such as these.


Why would I want to use this?
Community Patch is for those who want to run the CSL program on their DME. The main reason you would want to do this is if you are installing a CSL airbox and MAP sensor in your M3.


How do I use it?
Instructions on the various ways to program your DME, get setup for it, etc. are currently outside the scope of this post. The key steps are below:

1: Take a backup of your current program and tune files
2: Flash the appropriate program binary for your bootloader
3: Take the Tune (partial) binary and make any changes that you need to to it (common changes are things like VANOS offsets, disabling certain DTCs, etc.).
3a If you currently run a CSL program and tune and are converting to Community Patch you can use your existing tune, with the following caveats: (1: if using the M3 boot loader you need to set K_FR_T_ADAPT to 0x100. 2: If you are currently sending the Alternator (GEN_ST) signal over CAN you need to set K_GEN_CFG, K_GEN_TP and K_GEN_HYS accordingly. The easiest way to do this is to use the XDF reference below and apply the appropriate patches)


4: Flash the Tune (partial) binary to the car.

5: Enjoy.


Why would I want to migrate?
The key reasons you might want to migrate are:

1: You are running / want to run the CSL boot loader and want to also be able to send the Alternator signal over CAN. Community Patch supports this use case.
2: You are running the M3 boot loader and would like to resolve the Filling Regulator adaption issue.
3: You have encountered issues with emissions computer connectivity and would like this to be resolved.
4: You happen to want to read rf_psau over DS2 (e.g. via TestO or similar).


Changelog
211325000401PD31_Community_Patch_v1 (CSL Bootloader)
- Ability to configure sending of GEN_ST signal in DME4 CAN message (adapted from Terra's approach to this in his M3 boot loader binary).
- Fix for emissions computer connectivity as per SIB_12_11_06.
- Fix for rf_psau in DS2 serial frame as per https://nam3forum.com/forums/forum/s...he-csl-program.

211323000401PD31_Community_Patch_v1 (M3 Bootloader)
- Program ROM version changed to reflect 32300 bootloader.
- K_FR_T_ADAPT (Filling Regulator adaptation lockout time) changed from 0x96 (1.5 seconds) to 0x100 (2.56 seconds) to facilitate playing nicely with the 32300 bootloader.
- Ability to configure sending of GEN_ST signal in DME4 CAN message (adapted from Terra's approach to this).
- Fix for emissions computer connectivity as per SIB_12_11_06.
- Fix for rf_psau in DS2 serial frame as per https://nam3forum.com/forums/forum/s...he-csl-program.

Notes
- Note that the configuration parameters K_GEN_CFG, K_GEN_TP and K_GEN_HYS are in a different location in Community Patch to that of Terra's Modified Binary, therefore if migrating from Terra's Modified Binary you will need to configure these values as per the XDF.


Download
211325000401PD31_Community_Patch_v1 (CSL Bootloader)
211325000401PD31_Community_Patch_v1.bin.zip
211325000401PD31_Community_Patch_v1_Partial.bin.zi p

211323000401PD31_Community_Patch_v1 (M3 Bootloader)
211323000401PD31_Community_Patch_v1.bin.zip
211323000401PD31_Community_Patch_v1_Partial.bin.zi p

XDF
CSL_0401_Community_Patch_v1.xdf.zip


I have technical questions
Q1: What's with the boot loaders?
A1: The boot loader in the DME is used to perform initial setup of the DME before it boots into the operating system. The CSL boot loader (v2500) and the M3 boot loader (v2300) differ. The differences are EXTREMELY limited. The only differences between the two are the version strings and references to K_FSP_CONCEPT in both the Master and Slave tunes. The CSL and M3 tunes have these parameters stored in different places. This is what Terra figured out a workaround for to make reading codes function correctly. Aside from that there are no other differences between the two.

Community Patch for the M3 (2300) boot loader contains the modified version checks that Paffy originally designed, as well as a fix for K_FSP_CONCEPT (although this differs somewhat from Terra's fix in order to avoid a resultant bug).

Q2: How exactly does the fix for reading codes work?
A2: On both the Master and Slave the M3 boot loader looks in incorrect (for the CSL tune) locations for K_FSP_CONCEPT. The check in the boot loader code is for != 0 so we just need the byte where it is looking to be anything other than zero. On the Slave this is fine as the byte it looks at happens to be the first byte of the DTC configuration item for SMG CAN failure. This is a non-zero value so works as expected.

On the Master however it looks at the high byte of what is K_FR_T_ADAPT, which is a 2byte word that defines how long a set of conditions needs to be true before the Filling Regulator module will perform an adaptation. This value by default is 0x0096 which equates to about 1.5 seconds. The fix that Terra applied was to turn K_FR_T_ADAPT into a single byte coding 0x96, and use the previous byte, set as 0x01, for K_FSP_CONCEPT. Unfortunately this had the side effect of K_FR_T_ADAPT actually being treated as the value 0x9600. This meant that the conditions that should trigger a Filling Regulator adaption pretty much never occurred.

Community Patch fixes this in a more straightforward way (thanks to bmwfnatic). By setting K_FR_T_ADAPT to 0x100 the byte that the boot loader is looking at is now !=0 as required, and K_FR_T_ADAPT is now ~2.5 seconds instead of 1.5s. For the purposes of triggering the Filling Regulator adaption this change is inconsequential.