CSL '0401' Program Binary Disassembly Notes

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

[Niklas]

Appreciating this great work! Can't wait for the SMG to be finished so I can start on the 1st Gen DCT implementation: https://www.shop.rusefi.com/shop/p/ua-can-bridge

[karter16]

I've been doing a bunch of work on figuring out the SMG module in the slave binary. This is one of the areas the least information is available on, so there's a lot to work through and figure out. I've been making some great progress though.

There's 53 SMG functions in the slave binary, divided into the following sub-modules if you will:

- Clutch (manipulation of the clutch)
- Motor (e.g. motor torque and speed regulation)
- Shifting (changing of gears)
- Common/basic (init functions, the task functions, DPR, IPK, SK (safety concept), etc.)

Of note is that the SMG module has its own IPK messages to transfer critical values between the slave and the master. Some of these come straight off the SMG canbus and go via the IPK to the Master, others are generated by the SMG module functions and the results are sent to the Master (e.g. torque and engine speed regulation for the SMG).

The SMG also has its own freeze-frame generator for error reporting, so SMG-specific variables can be captured.

I've got more work and cross validation to do before I share everything, but for now here's the function that handles the well-known "limiter shift lights". "K_SMG_DWF_CFG_HS" is the parameter that can be changed to enable shift lights for non-SMG vehicles.

[S54B32]

Yeah, blocking filling seems interesting. What's TZ intervention? Is that ignition pull?

"TZ" should be german for "Transitor Zündung", that should be just a variable definition/name for ignition angle.

[karter16]

Yeah, blocking filling seems interesting. What's TZ intervention? Is that ignition pull?

Yup ignition pull (via the torque manager).

[Bry5on]

Bry5on just thinking about it further - it might be interesting to play with K_MD_STAT_ASC and see whether the behaviour you describe is more/less/equally related to either TZ intervention or filling intervention. Might be a useful piece of info.

Yeah, blocking filling seems interesting. What's TZ intervention? Is that ignition pull?