CSL '0401' Program Binary Disassembly Notes

[Slideways]

karter16

Is there anything that would suggest BMW used some of the code to develop the one-off E46 M3 CSL V8? I think that Terra said that the MSS54/HP has spots on the circuit board to drive two extra cylinders. Also, the S62 did run on MAFs.

[karter16]

I'll bet they tuned the car with an HFM in the loop at some point to get the cam baselines

Good call - that makes a lot of sense.


Sent from my iPhone using Tapatalk

[Bry5on]

I'll bet they tuned the car with an HFM in the loop at some point to get the cam baselines

[karter16]

Fun fact (which other people may already know, I just didn't) - the final RF calculation function in 0401 actually has provision for use of an HFM (MAF) sensor. The HFM sensor is assumed to to be plugged in to HFM1 (which in 0401 default config is the potentiometer for the CSL flap), but there are a number of parameters which can be set which configures the HFM1 A/D converter and ring buffer for a MAF sensor and derives the final RF from the ML value from HFM1. This is interesting as the final RF function in 0401 is not a copy/paste job from the standard MSS54HP code (e.g. it's an intentional inclusion, not a failure to omit). What I haven't looked into yet is whether any of the HFM tables differ from MSS54HP. I'm presuming that it would be calibrated for the standard M3 HFM sensor and cross-sectional area.

Here's the relevant line from the final RF calc function which I've posted before:



And here's the function which reads the A/D converter ring buffer:

[karter16]

Have identified the curve at 0xD002 - it describes the maximum torque to be applied by the Moment Manager in the event of a CAN SMG error state being stored in CAN_ED_SMG. The x axis is V (in km/h) and the y axis is torque (in Nm).

I've named the curve kl_md_can_ed_smg_max.



The curve is referenced in the function at 0x0001b0c2 which I have named md_can_ed_smg_max_calc()



This function in turn is run in one of the timed tasks (pretty sure it's the 20ms task but not 100% sure yet) if the gearbox type is SMGII.



and md_can_ed_smg_max itself is used in the Torque Limitation function of the Moment Manager.

[karter16]

Have published the XDF - figured it was worth it's own post so you can find that, along with the download link, here: https://nam3forum.com/forums/forum/s...p-csl-0401-xdf

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