CSL '0401' Program Binary Disassembly Notes

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

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

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

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

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

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

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

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

[MpowerE36]

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

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

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

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.

[karter16]

Okay - Here's the start of the disassembly to try to explain this. It's going to be too complicated for me to try to explain all in one go, so I'm going to start with the end (the final RF calculation) and then step backwards to the individual inputs to explain. Hopefully this makes sense.

The final RF (Relative Fill) value is calculated in the master in the function at 0x000218d0 (this is the function people will have seen referenced before when discussing this topic). For internal (to my brain) sanity purposes I have chosen to name this function "CSL_Calculate_RF_Final". This function runs in the segment task which means it runs every 120 crankshaft degrees of rotation (so very, very frequently). In addition to calculating RF this function actually also calculates RF5 (RF divided by 5 - legacy from earlier software versions where memory space was at a premium), ML (air mass), TL (load signal), and DAM (Delta Air Mass).

Here's the disassembly - you'll have to suffer through my non-consistent naming conventions sorry. The disassembly also tends to result in more verbose and harder to read C-code. Eventually I'll make a tidied up version of this code which will be easier to read, but for now this is what we have - I'll let you read through it - my explanation is below:




So essentially this function runs 6 times per cycle (720 degrees of crankshaft rotation). The key steps of the function are as below:

1: Calculate a value for rf based on the calculated cylinder pressure (I've called this cyl_charge_pressure, although I'm not completely sure this is the best way to describe it) and a factor that describes the normal mass of air in the cylinder.
2: Next we check to make sure that the engine is not in the process of starting. If it is then we use const values for RF and ML, but if it's not we carry on.
3: Next we check a parameter I've called K_RF_Calc_Config as this is a config byte which is used to define how this function operates. The way that it's set by default means that we carry on to line 29.
4: We take the rf value we looked up against the AlphaN table (this is the well-known 20x24 "CSL AlphaN Main" map) and adjust it by a modifying factor based on TABG.
5: We then do some scaling adjustments and set this to be our current RF value.
6: We then check K_RF_Calc_Config again and based on the default value we proceed to line 36
7: We then take a value I've labelled as "rf_pressure_adjustment" this is calculated in a separate function and is where the "2.5% limit" comes in. the value returned is the difference between RF and rf_pressure_adjusted (which we calculated on line 15) and limited to a max difference of 2.5 percentage points.
8: We then modify RF by this rf_pressure_adjustment.


And these steps pretty much explain why it has been thought that RF is adjusted by the MAP pressure up to 2.5%.

So why isn't it this simple? Let's keep working our way down.

9: on line 61 we calculate ML based on the RF value from step 8, the function then does a bunch of other stuff which is important for other things and then returns.

Okay cool, but how does this help? Next time the function runs the initial RF we take is "reset" to the AlphaN_TABG adjusted value, then has the "2.5%" adjustment applied again, but that's just the same thing as we had before isn't it? Sure as RPM and aq_rel (Relative Opening) change, and TABG changes the RF value will change, but how do we close the gap between that RF and the RF calculated from the MAP sensor?

The answer is in line 15.

rf_pressure_adjusted = (ushort)(((uint)cyl_mass_factor * (int)cyl_charge_pressure?) / 0xffff);

The function that calculates cyl_charge_pressure 0x000216e2, among many other things, takes the variable at 0x00ffef22 and uses it to calculate the new cyl_charge_pressure. What's in 0x00ffef22? It's a pressure related value which takes, as one of its inputs, ML (the ML we just calculated based on the RF adjusted by MAP pressure we just calculated).

I'll share these other functions in subsequent posts as it's a lot to lay out and take in, but I believe that this is how RF is ramped to the MAP-adjusted RF.

The above task and the cyl_charge_pressure tasks run in the segment task, so they are constantly adjusting RF and ML towards the 2.5% limited target RF.

Every 10ms the 10ms task fires and runs the function that recalculates the rf_pressure_adjustment (which is the 2.5% limited one). When it runs it's now comparing the newest RF against the MAP-based RF target (so in stable state the two values are closer than they were 10ms ago). If they're still more than 2.5 percentage points apart rf_pressure_adjustment will stay at 2.5 percent, if they're close it will scale down until they are the same.

This is why I retracted my statement about a limit of 2.5 percentage points per 10ms, as given the ramping is driven from the segment task, I can't be exactly sure how far it will get in the space of 10ms before it's re-evaluated. the number of times the segment task fires in 10ms varies depending on engine speed.

I'll share the details of the other functions I reference later (I have other things to do in my day also :-)), but hopefully this is the start of bringing clarity to this.

(Also if you think I've missed something/made a mistake/etc. please shout out! The only way we all learn is to search for the right answer together)

[karter16]

Update - I've highlighted in red two statements in my initial post of the MAP sensor which are incorrect. There is another layer of complexity which I'd missed, the statement about 2.5%/10ms is incorrect as additionally the calculation of ml based on the modified RF value then influences the calculation of pressure and the resultant pressure adjusted RF. I need some more time but wanted to update here ASAP to correct my previous statement.

Also apologies for the incorrect/overly simplified statement in my initial post. I got excited and posted - I should have taken more time and found this complexity first before presenting the information. I'm trying to reduce confusion on this topic not add to it 😔

Edit: From what I'm seeing so far I believe it works in approximately the same way as I describe (just achieved slightly more indirectly in that the adjusted RF is used to calculate the new ML value which in turn is used to calculate the new cylinder pressure which in turn is used to calculate the new pressure adjusted RF which in turn has the latest MAP sensor reading applied to it), I just now have more code to wade through to make certain I'm right.

[Bry5on]

Hell yes, thank you for breaking it down so clearly and cleanly. Those that have the MAP sensor next to the brake booster will have some additional smoothing from the hose acting as an accumulator/manifold too. Can’t tell you if this is a good or bad thing, but perhaps increasing that max above 2.5%/10ms would be worth the experiment.