CSL '0401' Program Binary Disassembly Notes

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

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

[Bry5on]

Wow, wild find

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

[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

[bmwfnatic]

Do the US emissions machines connect via OBD2 ?

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

In Netherlands cars starting from 2006 get scanned, if the readiness is good then the sniffer isn’t used.

[ac427]

Do the US emissions machines connect via OBD2 ?

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

[karter16]

That's nuts.

I always figured the fix was for some protocol edge case bug and not "let's give the computers a little longer to think". Amazing.

I was a little bit underwhelmed when I looked at the diff!


Sent from my iPhone using Tapatalk

[heinzboehmer]

Decided to have a quick look at the April 2009 program that was released to address issues with connectivity to emissions computers. This change never made it to the CSL version of the program as the CSL wasn't released in the USA.

Interestingly the difference (aside from checksum/crc bytes) appears to be very minor:



That byte represents the wait time for a certain message/connection action. Pre-fix this value was 0x19 (25ms) and post fix its 0x46 (70ms). Seems the fix was simply to wait longer in this particular scenario...

That's nuts.

I always figured the fix was for some protocol edge case bug and not "let's give the computers a little longer to think". Amazing.

[Slideways]

Decided to have a quick look at the April 2009 program that was released to address issues with connectivity to emissions computers. This change never made it to the CSL version of the program as the CSL wasn't released in the USA.

Interestingly the difference (aside from checksum/crc bytes) appears to be very minor:



That byte represents the wait time for a certain message/connection action. Pre-fix this value was 0x19 (25ms) and post fix its 0x46 (70ms). Seems the fix was simply to wait longer in this particular scenario...

It sometimes takes cycling the key, engine off and then on again, to get it to communicate.