CSL '0401' Program Binary Disassembly Notes

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

[karter16]

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.

[karter16]

Well it was worth a shot! I do wonder what some of the parameters were that seemed to be associated with DSC then. Different numbers between comfort and sport.

FWIW:

K_ASC_ALIVE: Defines whether or not the "ASC alive" counter should be respected.
K_ASC_MD_ABBRUCH: MD ramp on ASC abort (in the event of an ASC/CAN failure this defines the rate at which the torque manager blends out the ASC intervention).
K_DSC_STAND: (some sort of DSC version number I think. Its only use is to invert ASCXY in one of the CAN messages if a certain DSC_STAND is present.
K_DSC_TYP: DSC system type (Bosch, Teves, etc.)
K_ASC_A_TAU: Time constant for asc_ax/ay filter.

K_MD_ASC_BEGR: Limitation of ASC filling intervention
K_MD_ASC_CONTROL: Configuration parameters for ASC interventions (allows for ASC interventions to be blocked/turned off)
K_MD_STAT_ASC: Test parameter - Reject ASC interventions (0 = normal function, 1 = block TZ intervention, 2 = block filling intervention, 3 = block all interventions)

K_FGR_ASC_CNT: count/delay for ASC interruption of cruise control
K_FGR_WA_FEST_ASC: something to do with speed regulation under cruise control when ASC is active, haven't quite figured it out.

KL_TOG_ASCAX_DIFF & KL_TOG_ASCAY_DIFF: longitudinal and lateral acceleration inputs to the oil level sensor algorithm.

There's also some ASC/DSC inputs to the SMG system, but not relevant for those without SMG.

Let me know if there's any others you saw that you were interested in.

[Bry5on]

Update on this - unfortunately as far as I can tell the torque intervention is all executed on the DSC side. It simply sends the commanded value to the DME which implements it. I can't see that there's anything on the DME side that would indicate sooner what is going on, so don't see how this problem can be helped without changes on the MK60 side :-(

Well it was worth a shot! I do wonder what some of the parameters were that seemed to be associated with DSC then. Different numbers between comfort and sport.