CSL '0401' Program Binary Disassembly Notes

[Bry5on]

And no overflows! Impressive .

In my other car, I wrote my own motor controller code and found a sneaky overflow bug that commanded full throttle when a calculation overflowed above 55mph. I’d missed ONE mathematical operation in my giant excel sheet that hunted for overflows. Sure was freaky when that electric motor all of a sudden took off on my drive to work, and I was glad to have good brakes.

[karter16]

It occurred to me that it may or may not be immediately apparent to everyone as to why the program code contains so many scaling factors and offsets hardcoded into the program flow.

The reason for this is that the MSS54 CPU does not have an FPU (floating point unit). This means that the CPU is unable to natively perform floating point calculations and therefore all calculations are done with integer values. This is where all the bitshifts (multiplication/division by powers of 2) multiplication/division/addition/subtraction of parameters and consts comes in.

Say for example you have a filtered pressure reading from your MAP sensor of 800mbar. You now need to apply a correction factor of 1.03 (e.g. 800 * 1.03 = 824). The problem is that you can't represent 1.03 as floating point value, so you need to store it as a value that can be represented as an integer.We can't just round 1.03 to 1 because then we'll get 800 * 1 = 800, which isn't what we want. What we can do is represent 1.03 as 103 in an integer just fine, so we do that, we add a parameter into the partial binary and give it a value of DEC 103. Now we can apply our correction factor (e.g. 800 * 103 =82400). However now our result is 100 times too big. So what we do is modify the code to multiply our pressure by our correction factor and then divide the result by 100. This gives us (800 * 103 = 82400) and then we divide that by 100 to get 824. We've managed to get to the right end result without having to use floating point numbers.

This is a simple example, but you can easily envisage calculations which require lots of these scenarios and it can quickly get complicated, like this:

[karter16]

Thanks karter16

I know you are focusing on the MAP sensor at the moment but do you know how much influence the exhaust temperature sensor has on the cold start routine?

No worries - with the caveat that I haven't been through every reference to TABG (exhaust gas temp) I believe it is mostly used for calculating cat heating (including TKATM which is the cat temperature model) and the cat protection factor. Most of cold start factors that I have come across reference TMOT (and from memory TOEL in a couple of places, although I might be wrong). When I get a chance I'll look into this more and give you a more definitive answer.

[ac427]

Thanks karter16

I know you are focusing on the MAP sensor at the moment but do you know how much influence the exhaust temperature sensor has on the cold start routine?

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

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

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

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