CSL '0401' Program Binary Disassembly Notes

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

[karter16]

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

[karter16]

I'd very much like to get this set up for my gauge.s, Is the custom program closed source?

It's not currently released. I haven't got around to testing all the edge cases, plus I also have additional enhancements I want to make before I would release this wider. I'm not exactly sure yet how I'll be sharing it. To be honest I am wary of having my work out on people's cars from a risk perspective. The likelihood of issue is very low, but the impact could be high.

When I do make it available, in whatever way and to whatever extent, it will be free. I have no interest in making money off my hobby.

Watch this space I guess :-)

[yushpang]

Posted this in my build thread but thought it was worth putting here too:

Now that I'm setup for CAN logging I finally got a chance to try out my custom program and tune ROMs that allow for configuration of the additional CAN messages (7D0 and 7D1) in the partial binary (see here for the background: https://nam3forum.com/forums/forum/s...454#post310454).

The good news is that it all worked first time! (to be fair I put a lot of effort into checking and rechecking the code to make sure it was right)

First up I flashed the custom program to the DME and ran it with the standard tune. I've designed this such that if someone uses the custom program with a tune file not designed for it the additional functionality is simply disabled. Likewise if someone uses the custom tune with the standard program it is also gracefully handled.

I then verified that DME functionality was as expected. E.g. normal function and no additional CAN message activity. All was well.

I then added the new parameters to my tune file:



and flashed the tune. Sure enough everything still worked, and the 7D0 CAN message was present on the CANbus.

Here are the values being logged.



I've got some more scenario testing to do. e.g. test the 7D1 message as well, intentionally put bad data into the config parameters and make sure it's handled gracefully etc. but super stoked all is working so far as this is the most complex change I've made to the program so far!

Onwards and upwards - this functionality will be very useful to me as I dive into more refinement of my tune now I have high-frequency CAN logging available!

I'd very much like to get this set up for my gauge.s, Is the custom program closed source?