CSL '0401' Program Binary Disassembly Notes

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

[heinzboehmer]

Man, that's super cool. Good stuff!

[karter16]

Posted this in my build thread but thought it was worth putting here too:

Now that I'm setup for CAN logging I finally got a chance to try out my custom program and tune ROMs that allow for configuration of the additional CAN messages (7D0 and 7D1) in the partial binary (see here for the background: https://nam3forum.com/forums/forum/s...454#post310454).

The good news is that it all worked first time! (to be fair I put a lot of effort into checking and rechecking the code to make sure it was right)

First up I flashed the custom program to the DME and ran it with the standard tune. I've designed this such that if someone uses the custom program with a tune file not designed for it the additional functionality is simply disabled. Likewise if someone uses the custom tune with the standard program it is also gracefully handled.

I then verified that DME functionality was as expected. E.g. normal function and no additional CAN message activity. All was well.

I then added the new parameters to my tune file:



and flashed the tune. Sure enough everything still worked, and the 7D0 CAN message was present on the CANbus.

Here are the values being logged.



I've got some more scenario testing to do. e.g. test the 7D1 message as well, intentionally put bad data into the config parameters and make sure it's handled gracefully etc. but super stoked all is working so far as this is the most complex change I've made to the program so far!

Onwards and upwards - this functionality will be very useful to me as I dive into more refinement of my tune now I have high-frequency CAN logging available!

[karter16]

Have finished the CSL specific section of the Load Detection (Lasterfassung) module in the XDF. All parameters are named, with descriptions and correct conversion factors and units of measure.

Pretty much the only way this section will get more accurate now is if someone who has them shares the actual BMW names for these parameters, but that's really just a nice to have, it wouldn't change the understanding of what these parameters are and do.