CSL '0401' Program Binary Disassembly Notes

[karter16]

What year did the E46 M3 GTR come out?

It was a V8. I'm not sure which ECU it used though.

Also, which DME did the E39 M5 have, probably a previous generation MSS5x ECU.

Just came across this in the GTR thread - this is from the GTR product brochure:

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

[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

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

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]

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]

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]

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]

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]

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

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

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

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

[0-60motorsports]

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

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