CSL '0401' Program Binary Disassembly Notes

[ac427]

karter16 and bmwfnatic thank you both your selfless devotion undertaking this mammoth task.

[karter16]

karter16 Top man. Thank you for your selfless devotion undertaking this mammoth task.

❤️ lots of credit goes to bmwfnatic as well - wouldn't have been able to do all this without him. And of course to those who have done all the work on the earlier XDF, etc. It's a community effort :-)


Sent from my iPhone using Tapatalk

[karter16]

That's interesting. The CSL flap in factory software is never open under 1600rpm. This situation should only occur in an error state where the flap is stuck open. Or you've modified the binary to open earlier of course.

So I've been thinking about this and decided to have more of a look into it to see if I can figure out why BMW would go to the trouble for such a small variation.

I have been going through the function that determines the opening/closing of the flap and it turns out there actually more to it when it comes to deciding whether the flap should be open or closed. There are a range of different conditions that can contribute to the flap being opened.

Condition 1: Engine Speed (RPM) is greater than the FlapOpen RPM from the FlapOpen(Comfort/Sport depending) (this is the one we're expecting) plus a hysteresis value AND ML (air mass) is greater than a minimum value (20 kg/hr by default in 0401).
OR
Condition 2: Engine Speed (RPM) is 800rpm or greater AND a config parameter (0xA1DF is set to decimal 6 (it's 1 by default in the 0401 tune))
OR
Condition 3: SMG is in launch control mode OR SMG is "Schalten" (Shifting?)

Against all of these there is an additional condition that Ambient temperature must be above 3 degrees C or so (presuming I did the value conversion right).

So the flap open WDK table looks to be there for the launch control situation in production code, plus whatever the A1DF parameter does.

The same function also contains additional logic in the event that 0xA1DF is set to decimal 6. I haven't worked through this code yet to see exactly how that piece all works and whether setting the flap always open is as simple as setting 0xA1DF to 6.

[Bry5on]

So I've been thinking about this and decided to have more of a look into it to see if I can figure out why BMW would go to the trouble for such a small variation.

I have been going through the function that determines the opening/closing of the flap and it turns out there actually more to it when it comes to deciding whether the flap should be open or closed. There are a range of different conditions that can contribute to the flap being opened.

Condition 1: Engine Speed (RPM) is greater than the FlapOpen RPM from the FlapOpen(Comfort/Sport depending) (this is the one we're expecting) plus a hysteresis value AND ML (air mass) is greater than a minimum value (20 kg/hr by default in 0401).
OR
Condition 2: Engine Speed (RPM) is 800rpm or greater AND a config parameter (0xA1DF is set to decimal 6 (it's 1 by default in the 0401 tune))
OR
Condition 3: SMG is in launch control mode OR SMG is "Schalten" (Shifting?)

Against all of these there is an additional condition that Ambient temperature must be above 3 degrees C or so (presuming I did the value conversion right).

So the flap open WDK table looks to be there for the launch control situation in production code, plus whatever the A1DF parameter does.

The same function also contains additional logic in the event that 0xA1DF is set to decimal 6. I haven't worked through this code yet to see exactly how that piece all works and whether setting the flap always open is as simple as setting 0xA1DF to 6.

Oh man that’s super interesting. Like a secret raw mode. Interested to hear what you find as you dig in more. This might be easier to set to 6 than setting every flap open engine speed for those that don’t have the flap installed. Thank you for all this work!

[ac427]

So I've been thinking about this and decided to have more of a look into it to see if I can figure out why BMW would go to the trouble for such a small variation.

I have been going through the function that determines the opening/closing of the flap and it turns out there actually more to it when it comes to deciding whether the flap should be open or closed. There are a range of different conditions that can contribute to the flap being opened.

Condition 1: Engine Speed (RPM) is greater than the FlapOpen RPM from the FlapOpen(Comfort/Sport depending) (this is the one we're expecting) plus a hysteresis value AND ML (air mass) is greater than a minimum value (20 kg/hr by default in 0401).
OR
Condition 2: Engine Speed (RPM) is 800rpm or greater AND a config parameter (0xA1DF is set to decimal 6 (it's 1 by default in the 0401 tune))
OR
Condition 3: SMG is in launch control mode OR SMG is "Schalten" (Shifting?)

Against all of these there is an additional condition that Ambient temperature must be above 3 degrees C or so (presuming I did the value conversion right).

So the flap open WDK table looks to be there for the launch control situation in production code, plus whatever the A1DF parameter does.

The same function also contains additional logic in the event that 0xA1DF is set to decimal 6. I haven't worked through this code yet to see exactly how that piece all works and whether setting the flap always open is as simple as setting 0xA1DF to 6.

Could condition 3 be SMG launch mode?

[karter16]

Could condition 3 be SMG launch mode?

Yes I believe it is (at least the first half of the condition is) I haven't quite worked out the "Schalten" (Shifting) bit - I'm not quite sure why that's included/why it needs to be. Does that mean every time the gearbox is "Shifting" the flap qualifies to be open? That bit doesn't seem quite right, so maybe "Schalten" means something a little bit different?

Edit: bmwfnatic has confirmed that in context "Schalten" is definitely "while shifting" - he suggests that this is possibly to pre-empt the situation where downshifting brings RPM etc. above the threshold so the flap is preemptively opened for the "blip". This seems like a logical explanation for this condition.

[karter16]

Spent a little bit of time working through the 10ms task in the master binary to figure out what each of the functions it calls does. There's several still to work out but have made some pretty good progress. I've also figured out the inter-processor monitoring of the system timers and the EGAS Safety Concept Program Execution Control mechanism, as well as confirmed via the funktionsrahmen that the MSS54 uses dual-ported RAM to share variables between the two processors for non-critical purposes (which confirms my previous suspicion that that RAM space is shared). Also found in that same document that for sharing of variables for critical functions the IPK (inter processor communication) system is used. I'll try to find that mechanism in the code as well as would be useful to understand how it works.

[karter16]

I've been looking into the calculation of RF (relative fill) and how the MAP sensor etc. inputs into that, as it still seems to be an area of debate.

From what I've seen so far the following misconceptions that float around can be addressed:

Misconception 1: "The MAP sensor isn't used in normal use, the CSL runs pure AlphaN"
This is absolutely not the case, this may be due to a misinterpretation around how the status byte at 0x00ff807e is calculated, however in the happy path flow of the software the MAP sensor input is absolutely used (the difference between manifold pressure and ambient pressure is used to calculate an RF adjustment value). The amount of input it has appears to be limited to part throttle applications in low and mid-range RPM (hello drivability), but to say that the CSL runs pure AlphaN just isn't true (sorry AlphaN crew 😬)

Misconception 2: "The MAP sensor is only used as a backup when there is a TPS sensor failure"
Again as above, this isn't the case. The MAP sensor certainly IS used as a back up for various purposes including approximating RF when TPS input is implausible. It's also used (when the engine isn't running) to capture a p_umg replacement value if the DME onboard pressure sensor is in error state.


And this leads on to the most interesting of these misconceptions...

EDIT: I've adjusted two sentences in the below which were partially incorrect.

Misconception 3: "The MAP sensor input is limited in the code to a max 2.5% adjustment factor"
This one isn't wrong, so much as it's only part of the whole picture. It is true that in the function that calculates the RF adjustment as a result of pressure difference (it does this by taking the difference of final RF and RF calculated from pressure (p_umg - MAP_Pressure)) there are limits applied to the resultant rf adjustment to a max of 2.5 percentage points up and down. However the key thing that seems to have been missed is that the final RF value that it references to calculate the new RF pressure adjustment IS the pressure-adjusted (via ML) value from the previous time the function ran. This isn't a limiting factor it's a smoothing factor.


So what does this mean? In short, the MAP sensor is used to provide a pressure adjusted RF value which is used under part throttle conditions. The application of this pressure adjustment is smoothed to a maximum rate of change.

[heinzboehmer]

However the key thing that seems to have been missed is that the final RF value that it references to calculate the new RF pressure adjustment IS the pressure-adjusted value from the previous time the function ran. The function runs in the 10ms task, which means in the space of 100ms RF can be adjusted up down by up to 25 percentage points as a result of MAP sensor input. This isn't a limiting factor it's a smoothing factor.

This is some amazing insight. I hadn't seen this piece of info before. Thanks for sharing!

[S54B32]

I've been looking into the calculation of RF (relative fill) and how the MAP sensor etc. inputs into that, as it still seems to be an area of debate.

From what I've seen so far the following misconceptions that float around can be addressed:

Misconception 1: "The MAP sensor isn't used in normal use, the CSL runs pure AlphaN
This is absolutely not the case, this may be due to a misinterpretation around how the status byte at 0x00ff807e is calculated, however in the happy path flow of the software the MAP sensor input is absolutely used (the difference between manifold pressure and ambient pressure is used to calculate an RF adjustment value). The amount of input it has appears to be limited to part throttle applications in low and mid-range RPM (hello drivability), but to say that the CSL runs pure AlphaN just isn't true (sorry AlphaN crew 😬)

Misconception 2: "The MAP sensor is only used as a backup when there is a TPS sensor failure"
Again as above, this isn't the case. The MAP sensor certainly IS used as a back up for various purposes including approximating RF when TPS input is implausible. It's also used (when the engine isn't running) to capture a p_umg replacement value if the DME onboard pressure sensor is in error state.


And this leads on to the most interesting of these misconceptions...

Misconception 3: "The MAP sensor input is limited in the code to a max 2.5% adjustment factor"
This one isn't wrong, so much as it's only part of the whole picture. It is true that in the function that calculates the RF adjustment as a result of pressure difference (it does this by taking the difference of final RF and RF calculated from pressure (p_umg - MAP_Pressure)) there are limits applied to the resultant rf adjustment to a max of 2.5 percentage points up and down. However the key thing that seems to have been missed is that the final RF value that it references to calculate the new RF pressure adjustment IS the pressure-adjusted value from the previous time the function ran. The function runs in the 10ms task, which means in the space of 100ms RF can be adjusted up down by up to 25 percentage points as a result of MAP sensor input. This isn't a limiting factor it's a smoothing factor.


So what does this mean? In short, the MAP sensor is used to provide a pressure adjusted RF value which is used under part throttle conditions. The application of this pressure adjustment is smoothed to a maximum rate of change of 2.5% of max RF per 10ms.

I'm VERY happy that finally someone spends the time to bust this myth. Thank you for contributing this to the community!
Just for all the skeptical persons out there, could you please share some screenshots of the relevant parts of the disassambly to make your findings about this bulletproof?

[ac427]

I've been looking into the calculation of RF (relative fill) and how the MAP sensor etc. inputs into that, as it still seems to be an area of debate.

From what I've seen so far the following misconceptions that float around can be addressed:

Misconception 1: "The MAP sensor isn't used in normal use, the CSL runs pure AlphaN"
This is absolutely not the case, this may be due to a misinterpretation around how the status byte at 0x00ff807e is calculated, however in the happy path flow of the software the MAP sensor input is absolutely used (the difference between manifold pressure and ambient pressure is used to calculate an RF adjustment value). The amount of input it has appears to be limited to part throttle applications in low and mid-range RPM (hello drivability), but to say that the CSL runs pure AlphaN just isn't true (sorry AlphaN crew 😬)

Misconception 2: "The MAP sensor is only used as a backup when there is a TPS sensor failure"
Again as above, this isn't the case. The MAP sensor certainly IS used as a back up for various purposes including approximating RF when TPS input is implausible. It's also used (when the engine isn't running) to capture a p_umg replacement value if the DME onboard pressure sensor is in error state.


And this leads on to the most interesting of these misconceptions...

Misconception 3: "The MAP sensor input is limited in the code to a max 2.5% adjustment factor"
This one isn't wrong, so much as it's only part of the whole picture. It is true that in the function that calculates the RF adjustment as a result of pressure difference (it does this by taking the difference of final RF and RF calculated from pressure (p_umg - MAP_Pressure)) there are limits applied to the resultant rf adjustment to a max of 2.5 percentage points up and down. However the key thing that seems to have been missed is that the final RF value that it references to calculate the new RF pressure adjustment IS the pressure-adjusted value from the previous time the function ran. The function runs in the 10ms task, which means in the space of 100ms RF can be adjusted up down by up to 25 percentage points as a result of MAP sensor input. This isn't a limiting factor it's a smoothing factor.


So what does this mean? In short, the MAP sensor is used to provide a pressure adjusted RF value which is used under part throttle conditions. The application of this pressure adjustment is smoothed to a maximum rate of change of 2.5% of max RF per 10ms.

Nice work mate. I always thought it was strange for BMW to go to all that trouble to install a redundant component.

It's great to have the correct answer after all these years.

It also makes me feel a lot better after spending £800 on the MAP sensor and CSL rail, all those years ago 👍

[karter16]

I'm VERY happy that finally someone spends the time to bust this myth. Thank you for contributing this to the community!
Just for all the skeptical persons out there, could you please share some screenshots of the relevant parts of the disassambly to make your findings about this bulletproof?

Absolutely - It's a bit of a tangle and I posted pretty much as soon as I'd got it all figured out. I'm just tidying up my comments, etc. and will try to lay it out as clearly as possible. There's a few different functions in the mix so will do my best!

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

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

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