CSL '0401' Program Binary Disassembly Notes

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

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

Are we working to a point where we could use widebands with the factory ECU, to have live, on the fly, AFR corrections?

Oh my, that would be nice. Nobody working on this though, that’s a pretty massive rewrite. You might be able to just get that by using Z4M hardware.

Oh man that would be very cool. As Bryson says that would be a massive rewrite. It wouldn't just be about the actual code changes, but also the amount of research and investigation to understand, to extreme detail, how the MSS54 currently ingests the narrowband, plus how something like the MSS70 uses a wide-band and then figuring out how to bring them together. There's also all the hardware considerations (e.g. are there appropriate ADCs available on the MSS54, etc.). For the Civ fans it would be deity level difficulty. Not to say it couldn't be done, but it's certainly beyond my ability (although to be fair I think I said that about the CAN logging changes as well at some point, so maybe future-me will surprise myself ).


At the moment my main focus is on wrapping up understanding the CSL specific portions of the tune file and the code so that I can properly document all that and it's then available to the community as a reference. After that I really want to dig into the SMG code and work out the unknowns in that space, as once that's done we will have a truly complete XDF for 0401.

There's so many practical applications for what's being learned and uncovered and I certainly don't have the time or skill to chase them all. My hope is by making the information available it gives others the opportunity to pursue specific projects they are interested in.

Not to say I don't want to be involved in all these things, I just simply don't have the time to do it all!

[karter16]

karter16 Matt, have you looked into integrating into TunerPro RT? I believe the guys on the MS43 project have done so, you can check on their wiki, would be really cool way to log and tune in a single program.

I hadn't actually but will look into it - that sounds really cool and would streamline things a bunch. So much to do and so little time haha!

[Bry5on]

Are we working to a point where we could use widebands with the factory ECU, to have live, on the fly, AFR corrections?

Oh my, that would be nice. Nobody working on this though, that’s a pretty massive rewrite. You might be able to just get that by using Z4M hardware.

[Obioban]

Are we working to a point where we could use widebands with the factory ECU, to have live, on the fly, AFR corrections?

[bmwfnatic]

karter16 Matt, have you looked into integrating into TunerPro RT? I believe the guys on the MS43 project have done so, you can check on their wiki, would be really cool way to log and tune in a single program.