CSL '0401' Program Binary Disassembly Notes

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

[karter16]

I’ve always been curious to see if there’s a way to reduce latency in the DSC intervention torque re-application from the DME side. The DSC module itself has to have seen rather quickly that torque intervention has caused the tire to re-grip. It seems like it takes ages for the DME to command throttle again. But I don’t know if this is all DSC side code or both DSC and DME causing latency.

i went so far as to cut open an MK60 and phone a friend who was worked for TI when they designed the chip for ATE-Teves. Could never get the answer to what instruction set the chip has or of course the source code.

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 :-(

[terra]

Yeah I would guess that that's what they were for. The thing that puzzles me most is how the additional CAN controllers worked. When in extended/dev mode the code clearly initializes 4 controllers, all of the Intel 82527 variety and uses separate address space for each, but there's only two controllers on the board. It doesn't seem to make sense that there would be more at the other end of what the headers connect to. Confusing.


Sent from my iPhone using Tapatalk

Hmm, hard to say. From what I recall the prototype mss54hp I had seen looked pretty much the same as a standard mss54hp, except it had those headers populated. It could see those being used to interface to additional can controllers, but that's a wild guess. There probably were different boards used for different development phases

[karter16]

Presumably those unused headers above the CPUs would have been used to that end? I have seen prototype MSS5x boards with those headers populated. I don't remember if any of us ever fully mapped out those headers, but several pins do go to address pins iirc

Yeah I would guess that that's what they were for. The thing that puzzles me most is how the additional CAN controllers worked. When in extended/dev mode the code clearly initializes 4 controllers, all of the Intel 82527 variety and uses separate address space for each, but there's only two controllers on the board. It doesn't seem to make sense that there would be more at the other end of what the headers connect to. Confusing.


Sent from my iPhone using Tapatalk