CSL '0401' Program Binary Disassembly Notes

[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

[terra]

Okay I'm fairly sure that BMW must have used special development ECUs. It seems as though SG_TYP of Basic/Series means that it's a production ECU, and SG_TYP "application" means that it's a special development ECU. I'll post a full analysis when I get a chance, but I *think* that when the code is set to SG_TYP application it sets the addresses of the flash/NVRAM to be the external RAM of the dev ECU instead (so that the physical addresses of the code can be the same whether it's a production ECU or a dev ECU.

Given this it's reasonable to also expect that the dev ECU's would have additional CAN controllers as well I guess?

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

[karter16]

Hey Karter, there is already a post from Olza about SMG-CAN: https://nam3forum.com/forums/forum/s...4075#post54075

I did some Logs on SMG Can bus, there are not all IDs from your list present. The 0x7xx-IDs are not present on standart driving cycles. Maybe they are used in special situaions like bleeding oder kiss point learning triggered through INPA? I never saw them

I added my excel sheet (SMG2_LCAN.xlsx ) about SMG-CAN with some information, i hope it helps you a little bit...

Hey thanks for this - yes I've read through Olza's work. I guess you could say I'm going through the disassembly and independently verifying based on the disassembly. Not because I have any reason to doubt the work others have done, but I need to be completely sure that I'm not inadvertently introducing any mistakes into my disassembly, so need to figure everything out from primary sources.

FYI the 0x7xx IDs are optional/diagnostic ID's. They can be enabled by setting K_CAN_MESS1/2/3/4 and K_CAN_SEGM1/2 respectively. the "SEGM" messages are triggered in the segment task, so the frequency of them will vary with engine speed.

[Niklas]

I'm also working on fully documenting all the CAN messages for both the primary and secondary CAN busses. It's slow going as there's an awful lot of work to figure things out, sense check them against other functions that use the values, etc.

I'm about a 3rd of the way through having the detailed documentation for the Primary CAN completed, and will post it all up here once I get that done, before I move on to the detail for the secondary (SMG) CAN.

Hey Karter, there is already a post from Olza about SMG-CAN: https://nam3forum.com/forums/forum/s...4075#post54075

I did some Logs on SMG Can bus, there are not all IDs from your list present. The 0x7xx-IDs are not present on standart driving cycles. Maybe they are used in special situaions like bleeding oder kiss point learning triggered through INPA? I never saw them

I added my excel sheet (SMG2_LCAN.xlsx ) about SMG-CAN with some information, i hope it helps you a little bit...

[karter16]

Awesome - I can definitely look into this and see if I can figure anything out.