CSL '0401' Program Binary Disassembly Notes

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

[karter16]

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?

[karter16]

Maybe the 2nd port (normally SMG?) is used for calibration on engine testbed?

I know some ECUs like EDC16 have an additional CAN controller for calibration access. Most of the time, components are removed for series production, although still the traces are on the PCB. In some cases early ECUs are equipped with it.
From MSS60/65 I know 2 ports are used for CCP/XCP as 2 CPUs are used.

So I had wondered that too. But the additional 15 channels for CCP, and the related functions, are present for both Master and Slave. Which leaves a total of 4 sets of 15 channels, and hardware that supports 2 sets of 15 channels. I'll do some more digging and see if I can figure anything more out. Worth noting as well that, for each CPU, the first and second set of channels are managed with separate sets of memory locations for the buffers.

[Tomba]

Maybe the 2nd port (normally SMG?) is used for calibration on engine testbed?

I know some ECUs like EDC16 have an additional CAN controller for calibration access. Most of the time, components are removed for series production, although still the traces are on the PCB. In some cases early ECUs are equipped with it.
From MSS60/65 I know 2 ports are used for CCP/XCP as 2 CPUs are used.

[karter16]

karter16 do you think it could be related to usage of a "Plug-On Device" with dual port memory?

Yep I think that's exactly what it would be I think. I'm curious as well as the code makes use of a "second can controller" I've referenced it as "B" in above posts. The MSS54 has two Intel 82527 CAN communications chips which each serve 15 CAN channels. One of these is for the Master (primary) CAN and the other is for the Slave (SMG) CAN. What I'm not 100% sure of yet is whether the "Plug-On Device" if you will also adds additional CAN controllers? or if it's multiplexing the existing controllers somehow to work in a different space, but I haven't found evidence of that in the code yet. It seems simply that if the extended mode is enabled then it supports the additional CAN channels.

[MC346]

karter16 do you think it could be related to usage of a "Plug-On Device" with dual port memory?

[karter16]

Looks like the pre-decessor of INCA (ETAS).
Nice find!

Have you found pieces of code that could potentially be used for live adjustments? From what I believe is that some ECUs put (part) of the calibration-data (program) in RAM (memory) and adjust the RAM values to live adjust the data.

Might sound more easy than actually program it that way.

The last 20 or so functions in the program ROM seem to be related to the CAN B functions so I'm going to say yes. Furthermore I think that this function plays into it as well:



This function checks to see whether it can successfully write and read to "EXTRAM" test addresses. if it can it sets SG_TYP and SG_MODE to 2, if it can't it sets it to 1.

In the A2L SG_TYP == 1 means "Basic Mode" and SG_TYP == 2 means "Applications Mode". That in turn seems to govern whether the CAN "B" is used or not. So I think what the DME does is boots up and checks to see whether it has access to the extra external RAM that is used for storing the ROM as RAM for Gredi, and if it does then it puts itself in a mode where it expects to be communicated with via CCP (Gredi).

And yes, I doubt that there is a practical way for us enthusiasts to take advantage of this...

[MC346]

Looks like the pre-decessor of INCA (ETAS).
Nice find!

Have you found pieces of code that could potentially be used for live adjustments? From what I believe is that some ECUs put (part) of the calibration-data (program) in RAM (memory) and adjust the RAM values to live adjust the data.

Might sound more easy than actually program it that way.

Never thought i would ever read the word "INCA" in the context of MSS54..