CSL '0401' Program Binary Disassembly Notes

[karter16]

NOTE: The post below shows point-in-time understanding of this function. For a correct and complete disassembly of this function with accurate comments please see post #57

Ok here's the next one - this is Function 0x00021f2c - I've called this "CSL_RF_Calculate_Pressure_adjustment" and it runs in the 10ms task and establishes the 2.5 percentage-point limited rf_pressure_adjustment value stored in 0x00ffeed8.

It uses the difference between p_umg (ambient pressure) and MAP sensor pressure to lookup a multiplicative factor. This factor is then applied to the difference between rf_pressure_adjusted and RF. The result is then limited to the 2.5 percentage point variance and stored in rf_pressure_adjustment which in turn is used in CSL_Calculate_RF_Final above.

[Slideways]

Nice work!

I believe that terra , SliM3 , and olza had some ideas of how the MAP sensor worked in the old MSS54/HP comprehensive thread.

This is the thread I made a while ago (https://nam3forum.com/forums/forum/s...ensor-function) and the images from the E92 and CSL technical document:



IIRC, Terra said that BMW simplified the description of how the MAP sensor worked (mainly for the CSL).

Did BMW use a MAP sensor before the S54 or was that the first engine with it? (Maybe the first because previous DMEs were not as advanced?)

[karter16]

I think I might still be wrong (although I'm getting tired and that's never a good time to figure complicated things out) - Working it through some more I now don't think the adjusted RF value (up to a max of 2.5%) actually does continue to ramp towards RF from map pressure because the base RF from AlphaN is reset every time round the function, it therefore doesn't matter how far apart RF and RF from MAP are because the final RF value is only ever close to the RF from MAP value by 2.5%. It's now looking to me like the 2.5% limit is indeed correct...

I'll come back to this with fresh eyes later in case I'm now missing something that I wasn't earlier.

[MpowerE36]

I did this reverse engineering work long time ago. I can give you the solution if you are insterested.

[ac427]

I did this reverse work long time ago. I can give you the solution if you are insterested.

It would be interesting to see it.

[karter16]

I did this reverse engineering work long time ago. I can give you the solution if you are insterested.

That would be awesome - would you be willing for it to be shared with the community? as that's my ultimate aim is to have information available for everyone.


Sent from my iPhone using Tapatalk

[MpowerE36]

Here all my knowledge about the rf calculation of the BMW CSL engine. I hope this will be appreciated for its true value. You will have to do a bit of translation because I wrote it in French in the past but I am sure that will not be a problem.

[karter16]

Here all my knowledge about the rf calculation of the BMW CSL engine. I hope this will be appreciated for its true value. You will have to do a bit of translation because I wrote it in French in the past but I am sure that will not be a problem.

This is fantastic - thank you so much for this!


Sent from my iPhone using Tapatalk

[karter16]

MpowerE36 - thank you so much for this - the way you lay it out is fantastic and makes it so much clearer to understand. Your description of the rf_map as being an integrator is spot on and is possibly where my brain was trying to get to last night.

I *think* the point is that the manifold air pressure is used as a kind of process variable to calculate an integral component (think PID controllers) to correct steady-state error in the RF calculation. It's limited to 2.5% in order to prevent integral windup (which is essentially a runaway condition when the integrator sums to infinity without being able to pull the error term to zero).

At a high level my thinking is as follows:

1: RF is largely set from the AlphaN map. This map is based on the input variables aq_rel (relative opening) and N (engine speed).
2: The MAP sensor calculates a manifold air pressure based RF which feeds the integral component to eliminate the error-term in steady-state.
3: Under a sudden change in conditions (engine speed or aq_rel) the AlphaN map sets the new target RF instantaneously.
4: Under this condition it's entirely possible that the integral component saturates at +- 2.5% points of RF.
5: But that's okay, as the engine responds to the new aq_rel the RF from AlphaN and RF from MAP will begin to converge.
6: As they converge the integral component will fall back within it's saturation range and begin operating.

It makes perfect sense. Indeed as you note BMW essentially inactivate the integrator under WOT conditions and under high RPM conditions, it's active exactly where it's needed, which is driveability/steady state where final RF is relatively low anyway and the changes in it are lower. The MAP sensor input IS limited to +- 2.5% (of max RF, not current RF) but that doesn't mean it only has a small impact, it's entire purpose is to eliminate the steady state error between the AlphaN table and real-world conditions.

I don't know if anyone has done this yet, but if we apply the fix to "RF From MAP Sensor" via DS2 and log it and RF side by side I bet we see in drivability situations that the difference is less than 2.5% points (e.g. in the situations where it is useful the 2.5% points limit is NOT a limiting factor in what the MAP sensor contributes to the final RF)


Edit: a further thought - in drivability conditions RF is usually less than 15 (out of 100) or so, which means in those conditions the integral component can be as high as about 17% or so of current RF.

[karter16]

bmwfnatic and I have been talking and we think for the VE tuning process it may be better to disable the MAP sensor integrator so that the car is running pure AlphaN (with TABG adjustment). With the MAP integrator in the mix it's another variable. Large dataset probably mitigates this, but we think taking the MAP sensor out of the loop while doing the tuning could make it faster to get to the end result.

Taking the MAP integrator out of the loop is as simple as changing the configuration byte from 0x12 to 0x02 which keeps the TABG adjustment but takes the integrator out of the final RF calculation.


Sent from my iPhone using Tapatalk

[SliM3]

Nice work!

I believe that terra , SliM3 , and olza had some ideas of how the MAP sensor worked in the old MSS54/HP comprehensive thread.

This is the thread I made a while ago (https://nam3forum.com/forums/forum/s...ensor-function) and the images from the E92 and CSL technical document:

IIRC, Terra said that BMW simplified the description of how the MAP sensor worked (mainly for the CSL).

Did BMW use a MAP sensor before the S54 or was that the first engine with it? (Maybe the first because previous DMEs were not as advanced?)

Yeah, I have an IDA Pro disassembly I completed a while ago but my interpretation as to how and when the MAP sensor is integrated is a little different than what's being described here, and what I've experienced playing around with the tune (swapping ram address, disabling flags, etc.). Never the less cool to compare notes, albeit I'm not too familiar with the tool being used here.

[karter16]

Okay here's the calculation of the MAP Sensor based Integral component with updated variable names and comments now that I've had a chance to digest MpowerE36's document.

In naming the various variables I've tried to do it in the same way I imagine BMW would have originally. Any variables I've named are lowercase. Known variable names from BMW are all caps.

p_ask: Pressure Ansaugkrümmer (Manifold Air Pressure)
p_kvm: Pressure Krümmervakuum (Manifold vacuum)

All other variables are based on this naming.

[karter16]

I'm working now on the pressure and air mass functions - found the PT1 filter functions and matching up the disassembled code to the calculations.

I realized as well a slight nuance to the code at the end of the calculation of rf_p_ask_i (the error condition behavior) is that when a WDK error occurs the code is ramping rf_p_ask_i to zero. Will update the comments.


Sent from my iPhone using Tapatalk

[ac427]

p_ask: Pressure Ansaugkrümmer (Manifold Air Pressure)
p_kvm: Pressure Krümmervakuum (Manifold vacuum)

Sorry for the dumb question but aren't the variables above just opposites of eachother?

[karter16]

Sorry for the dumb question but aren't the variables above just opposites of eachother?

Not dumb at all as there's a lot of different variables used and naming them appropriately is also challenging.

p_ask: is the air pressure as measured by the MAP sensor (once it's been filtered, scaled, etc)

p_kvm: is a measure of vacuum in the manifold and is calculated as P_UMG (ambient pressure from the DME pressure sensor) minus p_ask. So essentially the difference between ambient and what the MAP sensor sees.

If ambient pressure (P_UMG) is 1000mbar and MAP sensor is measuring 700mbar (p_ask) then manifold vacuum (p_kvm) is 300mbar.


Edit: I should more correctly define p_ask as “Absolute Manifold Pressure” I will update this.