CSL '0401' Program Binary Disassembly Notes

[SliM3]

Do the US emissions machines connect via OBD2 ?

In the UK we just have the pipe up the exhaust and hold engine RPM steady.

They check readiness monitors here in GA via OBD2.


Sent from my iPhone using Tapatalk

[karter16]

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.

[Bry5on]

Wow, wild find

[Tomba]

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.

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

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

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

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

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

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.

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

[MC346]

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

[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

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

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