CSL '0401' Program Binary Disassembly Notes

[Tomba]

Oh man that would be very cool. ...

Likely you would need seperate wideband control units to control the widebands as I suspect the stock hardware (MSS54) isn't able to control pump current for the widebands. Then there is an issue with the ADC conversion, I believe the stock lambdasondes input voltages are increased by amplification circuit to optimize the full range of the ADC. 1.2V lambda sonde voltage might be 5V input on the ADC. The wideband control units output voltage will need to work in a relatively small range (0-1 V vs 0-5V) and might reduce accuracy and resolution.

I work with OEM engines and ECUs for testing and some OEMs have implemented a "wideband" function in their narrow band application. Once this function is enabled the input voltage present the actual lambda value. 1V = lambda 1, 0.8V = lambda 0.8. Mainly used to control the mixture during full load. The ETAS LA-4 wideband is able to feed a 0-1V signal for this. I wouldn't expect this function to be present on MSS54, but might be an idea to implement. As you said, it will take much work as the original narrow band signal is used for many sub functions. Might be able to turn the "wideband signal" in two, one converted to actual lambda and one converted to narrowband lambdasonde voltage. Enough to think about.
I do think it is not necessary, as I never heard people getting different lambda ratios during full load. Stock corrections should be able to correct it. I can understand the desire for a load depended enrichment factor during full load, rather than the current ambient pressure based one for charged applications. I would expect that with your current knowledge it shouldn't be much trouble to change the variable x/y axis for a map?!


Tuning and logging with tunerpro,
Depends were you send the live data to, if you use CAN and connected K+DCAN to the OBD port were also vehicle CAN is connected (pin 6 and 14) you will see the cluster going bananas sometimes. I suspect commands send to K line are also transmitted over CAN and interrupt the vehicle CAN. Experienced this on my E46 320i (M54B22/MS43). Would need 2 cables connected to each bus (k-line/ CAN) (one flashing, one logging) or all over k-line (DS2 command).

Live tuning would be my preference. But how to implement? It would mean certain amount of maps or whole areas are put in RAM and read from RAM instead of ROM/FLASH (don't know if that is already done?). Commands from CAN/Kline would tell the uP to change the address location and value and update the map. I'm using OLS300 now and need 2 ECUs to switch as there is one memory for master and one for slave.
I believe there are programs that export data real time/once changed. Make a program to detect changes, if change is present send location and value to ECU, ECU updates and voila! Once done tuning, flash calibration. I doubt it would be that easy

[karter16]

I noticed a couple of weeks ago in my logs that when I turned AC on it pushed lambda lean by about 5% and it stayed that way, e.g. it didn't converge back to 1 like you'd expect.

I've been pretty puzzled by this and have been doing some logging to make sure that the KKOS requests to the moment manager for torque appeared valid, etc. All of that looked good, and so I've been digging into the disassembly, working through the path of the idle controller, etc.

What it seemed to me was that the issue lay somewhere within the calculation of RF, which was causing a persistent gap between what was expected and what was actually happening. the Funktionsrahmen makes mention of the KKOS (aircon) unit having it's own adaptation integrator and that's the area I've been chasing.

This afternoon I bumped in to the K_FR_T_ADAPT parameter, which is a fairly innocuous looking parameter that tells the Filling Regulator module how long an adaptation should take.

What is the Filling Regulator module? in the words of the funktionsrahmen:

The filling controller ensures the steady-state adjustment of the actual filling to the target filling. The filling controller is a PI controller, whereby the I component is switched off (current value is frozen) when the throttle valve is open enough that the engine is no longer throttled, or when the deviation of the current throttle valve position from the target value for the position controller is greater than an applicable constant. The P component is set to zero when the condition B_WDK_KEINE_THROTTLE is active.

So why is K_FR_T_ADAPT of interest all of a sudden? It happens to be the parameter which Terra changed from a word to a byte when he made the modified 0401 binary to work with the standard M3 32300 bootloader.

By default K_FR_T_ADAPT is a word and is loaded with 0x0096. Changing it to a single byte (0x96) is of course fine, as the high byte isn't needed to represent the 150 ticks (running in the 10ms task this equates to 1.5 seconds). Terra changed the instruction that loads K_FR_T_ADAPT into FRA_TIMER to treat K_FR_T_ADAPT as a byte rather than a word, however because the 68k is big-endian this had the effect of loading FRA_TIMER with 0x9600 rather than the intended 0x0096.

This means that the FR adaptation process that is meant to cycle every 1.5 seconds actually cycles every 6.4 minutes instead. This bug prevents the filling regulator from adapting quickly to changing filling conditions.

I verified this via logging:

Here is FRA_TIMER (as you can see I gave up watching it decrement after 30 seconds)



I then modified the program rom to fix this bug. The way I've fixed it is slightly hacky because I was doing it quickly to prove a point. What I've done is left FRA_TIMER being loaded with 0x9600, but then modified the instructions where FRA_TIMER is used to treat it as a byte, looking at the MSB, so each time it decrements the MSB is decremented by 1, and the LSB is entirely ignored. Not the cleanest, but an easy way to prove this out without dealing with injecting extra instructions into the flow.

Here's the after - FRA_Timer decrements to 0 in 1.5 seconds as expected.



So, will this solve my aircon/lambda issue? I'm not sure. I need to log for a while in different conditions to be able to say for sure, however I will say that my initial quick check seems promising:


Aircon compressor running - average lambda of 1.005


Aircon compressor off - average lambda of 1.003


I need to run logs for multiple days in a range of conditions to be sure, but it does look a little bit promising.

Certainly having the filling regulator module operating as intended won't be hurting!

[0-60motorsports]

Awesome work. I wonder if this had something to do with the infamous CSL idle hunt with AC on.

[Bry5on]

Well that would explain why my car idles perfectly smooth and tracks stoich on the 32500 CSL bootloader but yours doesn’t! Wild find!

[karter16]

Well that would explain why my car idles perfectly smooth and tracks stoich on the 32500 CSL bootloader but yours doesn’t! Wild find!

Crazy right!?!

I've been doing more logging this week and with the car up to temp and steady-state idling for several minutes the small difference in average lambda between aircon off and aircon on is exactly aligned with the difference between the VE cells the car sits in with aircon off vs aircon on. In other words the variance I'm measuring between the two states is exactly explained by differences in the VE table, as opposed to the previous much larger variance that didn't correlate to the VE table.

I'm going to do some more logging to be absolutely certain but my optimism that this has addressed the issue I was seeing is continuing to grow.

[ac427]

Does this also help in the pursuit of an answer to the idle hunting on the native boot block CSL firmware?

I was wondering if altering FRA_Timer might help?

[0-60motorsports]

Does this also help in the pursuit of an answer to the idle hunting on the native boot block CSL firmware?

Thats all i want fixed too LOL

[karter16]

Separate things. What I've addressed is specific to the Terra modified binary. If it affects the standard CSL binary as well it's not related to this.

Would be great to capture the behavior on logging as that would help narrow it down. Bit hard as as far as I'm aware I can't reproduce it on my car.


Sent from my iPhone using Tapatalk

[0-60motorsports]

Separate things. What I've addressed is specific to the Terra modified binary. If it affects the standard CSL binary as well it's not related to this.

Would be great to capture the behavior on logging as that would help narrow it down. Bit hard as as far as I'm aware I can't reproduce it on my car.


Sent from my iPhone using Tapatalk

If you tell me How to log it I can try. My car always does it

[karter16]

If you tell me How to log it I can try. My car always does it

Sure - I'm away from my laptop for the next few days, so let me come back to you on a test scenario. What logging options do you have available? TestO or similar?

Also are you running CSL cams or standard cams?

[0-60motorsports]

Sure - I'm away from my laptop for the next few days, so let me come back to you on a test scenario. What logging options do you have available? TestO or similar?

Also are you running CSL cams or standard cams?

I have neither but I can get them off you can give me please. I have standard cams, or CSL intake setup with CSL MAP sensor and full SS V1 catless resonated full exhaust system. SMG too.

[karter16]

I have neither but I can get them off you can give me please. I have standard cams, or CSL intake setup with CSL MAP sensor and full SS V1 catless resonated full exhaust system. SMG too.

Yep sure - will message you next week with some details.

Given you're on standard cams I do wonder whether this is actually tune related. As far as I know neither Bryson nor I see this problem on our tunes, both of which have had a lot of work down in the low RPM/partial load area. The CSL cams have quite different map/fuelling requirements to the standard cams, so it might be explained by something as simple as this. Anyway, some logging should help figure that out.

If this is happening for those with CSL cams then that's another matter.

[0-60motorsports]

Yep sure - will message you next week with some details.

Given you're on standard cams I do wonder whether this is actually tune related. As far as I know neither Bryson nor I see this problem on our tunes, both of which have had a lot of work down in the low RPM/partial load area. The CSL cams have quite different map/fuelling requirements to the standard cams, so it might be explained by something as simple as this. Anyway, some logging should help figure that out.

If this is happening for those with CSL cams then that's another matter.

Ok awesome! Take your time. Ive been living with this for years LOL. Thank you.

[karter16]

Update 16 September 2025:
The latest disassembly archive can be found here: https://github.com/karter16/CSL_0401...2025_09_16.gar

There is a lot of additional work been done since the March update - off the top of my head things like:

• CSL RF calculation path built out
• Operating System functions identified and built out
• SK (safety concept) self-test functions identified and built out
• A lot of the EEPROM read/write/test operations identified and built out
• CANBUS module identified and built out
• IPK functions identified and built out
• Timed tasks identified and built out

[PistenPeter]

Update 16 September 2025:
The latest disassembly archive can be found here: https://github.com/karter16/CSL_0401...2025_09_16.gar

There is a lot of additional work been done since the March update - off the top of my head things like:

• CSL RF calculation path built out
• Operating System functions identified and built out
• SK (safety concept) self-test functions identified and built out
• A lot of the EEPROM read/write/test operations identified and built out
• CANBUS module identified and built out
• IPK functions identified and built out
• Timed tasks identified and built out

Top! Thanks for sharing!