MSS54HP CSL '0401' Community Patch binaries

[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)
Please Note: I have binaries ready, but because I am not running the CSL boot loader currently I can't personally test it until I have time to swap over to the CSL boot loader. If you wish to volunteer to be the beta tester for this please let me know. Otherwise I'll make the files available as soon as I've personally tested them.

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.

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

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

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

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

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

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

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.

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

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

[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

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

[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

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