CSL '0401' Program Binary Disassembly Notes

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

[Bry5on]

What are you thinking? No reason why we couldn't influence those messages. Not all the inputs to the DSC are direct or from the DME (e.g. LWS (steering angle sensor) -> DSC is direct), but aside from that can't think of any other major blockers offhand.

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.

[karter16]

When you’re through all this, digging into traction control intervention command/responses would be fun

What are you thinking? No reason why we couldn't influence those messages. Not all the inputs to the DSC are direct or from the DME (e.g. LWS (steering angle sensor) -> DSC is direct), but aside from that can't think of any other major blockers offhand.

[Bry5on]

When you’re through all this, digging into traction control intervention command/responses would be fun

[karter16]

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.

[karter16]

Have been working on this on and off for a while - here's a more complete view of how the DTC configuration table works and what each of the values means.

Of note is that of the various "strategies" that exist to delete DTCs, the control byte (byte 12, or 13 if you're not using zero-based indexing ) is the only one that matters.

[karter16]

I remember this post some time ago:
https://nam3forum.com/forums/forum/s...l-began-m3-csl

Nice one thanks very much for this - I very vaguely recalled having seen something about a development ECU once, but couldn't remember where or the context!

[S54B32]

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?

I remember this post some time ago:

https://nam3forum.com/forums/forum/special-interests/coding-tuning/33062-where-it-all-began-m3-csl

[MC346]

Maybe they did not even communicate via the vehicles CAN Bus, but rather accessed the PoD directly.