CSL '0401' Program Binary Disassembly Notes

[karter16]

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

Yup ignition pull (via the torque manager).

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

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.

[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

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

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

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

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

well those ELF files make things easy :-)

Here's the MSS65 rf_berech()

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

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

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

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.

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