CSL '0401' Program Binary Disassembly Notes

[bmwfnatic]

I have this horrible nagging feeling that one day I'm going to declare my efforts "complete" and the next day someone will be like "oh btw, here's the source code for the CSL" lol. There's definitely a couple of people out there who have more CSL-specific info.

This will 100% happen one day, we know it's out there, and people love to gate keep until there's no point anymore.

[karter16]

Sure would be nice if we could get access to some MSS54 ELFs

I have this horrible nagging feeling that one day I'm going to declare my efforts "complete" and the next day someone will be like "oh btw, here's the source code for the CSL" lol. There's definitely a couple of people out there who have more CSL-specific info.

[terra]

Yeah hard to say for sure. I also have a suspicion that the some of the CSL stuff was borrowed from the MSS6x project given the development timelines, but the two projects very well could have had different naming conventions. Though a lot of names are shared, so it might just be their convention is a little more fluid and it more came down to whichever engineer started writing the code.

As far as m vs mzyl -- I think they probably would have noted that the value is a per cylinder calculation in the naming scheme, though perhaps m_zyl would have been the convention on the MSS5x

Sure would be nice if we could get access to some MSS54 ELFs

[karter16]

Here's mzyl_berech(). This is what I'd previously identified as m_calc(). I'm not 100% sure that the function/parameter/variable names that I've pulled through from MSS65 are what BMW ACTUALLY used in the MSS54 code. I think it's more likely that PSAU is p_saug for example, in line with the way other pressure and temp variables were named in the MSS54. I think too that MZYL was possibly just M, etc. but I'm definitely going to opt for known actual names over made up names, so have pulled through the MSS65 naming where there wasn't already a 100% known name from MSS54. ? at the end of a variable name represent where I don't have a definitive name, not necessarily that I have any uncertainty about what it is/does.

[karter16]

Ahh this is so satisfying for my brain.

I've gone through rg_berech() (MSS65) and compared it to rg_m_calc() (my MSS54 disassembly) and the rg (rest-gas) calculation is effectively the same. I've been able to match everything up and identify the actual names for the maps and parameters. This confirms that my understanding of how it was working was pretty much on the money.

The only significant difference between the two (aside from MSS65's bank handling, and differences in base units) is that the MSS65 function includes a lookup to a table which gives a delta adjustment based on expected intake manifold pressure. This isn't included in the MSS54 function although I haven't yet figured out whether it's effectively accounted for elsewhere in the calculation path.

The other thing of note is that the MSS54 has an unused option to just lookup rg mass from a lookup (KF_RG_M) the equivalent lookup doesn't exist in the MSS65 code.


MSS54 rg_berech()

[karter16]

If I had to guess, the name for the CSL one would be something to the effect of KF_RF_SOLL (which now I see is something you came up with as well) or perhaps KF_AQ_REL_SOLL(_RF?)

The MSS6x seems to handle things a little differently. The MSS65 v113 prototype seems to have KF_EGAS_SOLL_DK (rf target from throttle opening area). There's also a KF_EGAS_SOLL_LLS (rf target from idle valve opening) -- presumably the two outputs are added together. The MSS5x instead generates an aq_rel from the throttle valve and idle valve openings and then that's fed into the big map. I imagine the extra processing power on the MSS6x made them try separate maps rather than combining the two air sources. These maps sit on the ignition processor like the "standard" RF map on the non-CSL. As far as I can tell there's no similar map on the injection side -- I suspect on the CSL it moved to master/injection side for processing speed purposes.

Yeah agreed - the MSS65 has a different approach to RF calculation. In V113 it's actually configured to use an HFM to assist in the calculation of base RF before applying the air mass calculations. The path where KF_EGAS_SOLL_DK/LLS is used to calculate rf_aq and rf_mzyl_ml_aq isn't actually followed given what K_MZYL_CFG is set to.

You're right it could be kf_rf_soll, I certainly think it's likely that the variable that it drives is rf_soll, I'd kinda followed the standard naming convention to get KF_RF_N_DR_REL but absolutely could be kf_rf_soll or even kf_rf_soll_n_dr_rel.

[terra]

If I had to guess, the name for the CSL one would be something to the effect of KF_RF_SOLL (which now I see is something you came up with as well) or perhaps KF_AQ_REL_SOLL(_RF?)

The MSS6x seems to handle things a little differently. The MSS65 v113 prototype seems to have KF_EGAS_SOLL_DK (rf target from throttle opening area). There's also a KF_EGAS_SOLL_LLS (rf target from idle valve opening) -- presumably the two outputs are added together. The MSS5x instead generates an aq_rel from the throttle valve and idle valve openings and then that's fed into the big map. I imagine the extra processing power on the MSS6x made them try separate maps rather than combining the two air sources. These maps sit on the ignition processor like the "standard" RF map on the non-CSL. As far as I can tell there's no similar map on the injection side -- I suspect on the CSL it moved to master/injection side for processing speed purposes.

Closest equivalent on the MSS60 prototype (which is likely pretty close to final MSS65 code) is KF_EGAS_SOLL_AQ. There's also a KL_AQ_ABS_LLS- it seems like they went back to the concept of just transforming the idle valve opening as 'adding to' the throttle opening, and just stuck with units of area instead of generating an "aq_rel" value (though as you've found, an aq_rel value is ultimately generated to do stuff on the injection side)

I feel relatively confident the psau object and associated naming convention is pretty close to what's in the CSL (minus bank1 / bank2 stuff probably) though I need to dust off my binaries and disassemblies and look closer. Reproduced relevant stuff below

 .std_appl 000608c4 00000084 ..\..\output\inj\obj\psau.obj
K_PSAU_STEIGUNG 000608c4 00000002
K_PSAU_OFFSET 000608c6 00000002
K_PSAU_DIAG_MAX 000608c8 00000002
K_PSAU_DIAG_MIN 000608ca 00000002
K_PSAU_ERSATZ 000608cc 00000002
K_PSAU_ADAPT_MAX 000608ce 00000002
K_PSAU_ADAPT_MIN 000608d0 00000002
K_PSAU_TAU 000608d2 00000001
K_PSAU_MZYL_A 000608d4 00000002
K_PSAU_MZYL_E 000608d8 00000002
K_PSAU_MRG_A 000608dc 00000002
K_PSAU_MRG_E 000608e0 00000002
KL_PSAU_ZAHN_OFFSET 000608e2 0000002a
KL_PSAU_MZYL_DASP 0006090c 0000001e
KL_PSAU_WF_DASP 0006092a 0000001e[

.text 00033398 000009a8 ..\..\output\inj\obj\psau.obj
psau_diag 00033398 000000c8
psau_ausw_10ms 00033460 00000120
psau_init 00033580 00000128
psau_10ms 000336a8 00000054
psau_adaption 000336fc 00000080
get_qidx 0003377c 00000034
get_mw 000337b0 0000007c
psau_ausw 0003382c 00000504
psau_auf_bank1 00033d30 00000008
psau_auf_bank2 00033d38 00000008

psau                            .vars       .std_vars      ..\..\output\inj\obj\wf_fkt.obj
                                                                  ..\..\output\inj\obj\ti_fkt.obj
                                                                  ..\..\output\inj\obj\rps.obj
                                                                  ..\..\output\inj\obj\rg.obj
                                                                  ..\..\output\inj\obj\rf.obj
                                                                * ..\..\output\inj\obj\psau.obj
                                                                  ..\..\output\inj\obj\mzyl.obj
                                                                  ..\..\output\inj\obj\hfm.obj​
​

[karter16]

Okay exciting.

We now have the definitive name for what I termed aq_rel_rf!

It's dr_rel_roh (drossel-relativ) relative throttle signal.

In the MSS65 it's calculated in aq_5ms_bank:



The factor is obtained from KL_AQ_REL_MAX_ENTDR (what I'd called kl_aq_rel_rf_fakt). Super satisfying to know what actual name for this is. It also gives us a bit more insight into exactly what it's intended to correct. Essentially it's accounting for the fact that a given aq_rel at low RPM has a different effect compared to at a high RPM due to flow and manifold dynamics.


Edit - by extension this also presumably gives us the correct name for the CSL AlphaN table.

The standard table for the M3 (the lower resolution one) is KF_RF_N_AQ_REL. That means the CSL one is presumably KF_RF_N_DR_REL.

[karter16]

Calculation for exhaust gas back pressure is pretty much identical:

MSS54 (0401)


MSS65


MSS65 stores rg parameters in a struct which is why there are all of the pointer offsets

[karter16]

Okay - been having a bit of a look at this in more detail. It's extremely useful. As you suspect terra there are some fairly strong similarities between 0401 and this. They are far from identical, and the MSS65 code seems to be more advanced in some ways. But I've been doing a comparison on the residual gas mass functions. Good news is that my interpretation of them was correct. Secondly there's a bunch more parameter names I'm going to be able to confirm out of this.

Very cool.

[karter16]

well those ELF files make things easy :-)

Here's the MSS65 rf_berech()

[terra]

Yeah there's actually some interesting insights in there. Have to interpret in context since it's early MSS65 rather than MSS54 info, but even skimming through it it's clear that the MSS65 concepts are evolution of the MSS5x and these are early enough prototypes that I suspect a lot of it is closer to the MSS5x counterparts than the final MSS6x. I imagine the map sensor stuff will be fairly close to the CSL implementation given these date back to 2002-2003 and the actual production M5 did not end up using a map sensor to my knowledge

[karter16]

There's a lot of information in those files - the MAP files have a listing of all the objects, in order, with function names.

[karter16]

So kinda tangentially related, but I found this repo when scouring the internet for MSS6x stuff https://github.com/jakkuh/MSS65-Info and within that there seems to be something related to Gredi https://github.com/jakkuh/MSS65-Info...ain/tools/MCS4

I don't think any of it is particularly useful as end users (even all the MSS6x binaries seem to be truly ancient - I doubt they'd function properly on retail hardware), but perhaps worth digging into a little more. I also need to look into info about that "2+ tb damos dump". The only similar collection I had seemed to be missing anything related to BMW M from what I remember.

Awesome find!!

I'm going to be scouring through this - there's a bunch of stuff in there about p_saug (manifold air pressure) and rg_m (residual gas mass) which will be super helpful cross references.

[terra]

If anyone is interested this http://www.kleinknecht.com/en/software_gredi4.htm appears to be the software that BMW used to testbed tune the S54 (and presumably other engines/DMEs of the era).

There's a reference to "Gredi" in one of the funktionsrahmen documents and I saw it and was curious and a bit of a hunt unearthed this. This also explains what I'd previously noted about the "B" canbus channels which appear to be for transfer of data. Pretty sure the CAN Control Protocol that Gredi uses fits the bill.

So kinda tangentially related, but I found this repo when scouring the internet for MSS6x stuff https://github.com/jakkuh/MSS65-Info and within that there seems to be something related to Gredi https://github.com/jakkuh/MSS65-Info...ain/tools/MCS4

I don't think any of it is particularly useful as end users (even all the MSS6x binaries seem to be truly ancient - I doubt they'd function properly on retail hardware), but perhaps worth digging into a little more. I also need to look into info about that "2+ tb damos dump". The only similar collection I had seemed to be missing anything related to BMW M from what I remember.