CSL '0401' Program Binary Disassembly Notes

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

[ac427]

Just came across this in the GTR thread - this is from the GTR product brochure:

Thanks Matt, I wonder why BMW went for the MSS70 in their S54 powered Z4's. Perhaps the MSS54 was getting old by then. I can't imagine they needed more processing power or input/output capability.


Anyway, what are the next subjects for the 0401 disassembly?

[bmwfnatic]

I used a self compiled Ghirda by pulling a commit with CPU32 support, that has worked for me MarkD_M5

[MarkD_M5]

Hi Matt,

Thanks for the reply!

So it seems that the CPU.sla file is the output of the SLEIGH compiler, but I'm bit sure what triggers that to compile.

On another site , I saw this post:

>>>>>>>>>>>>>>>>>>>>

Re: 12587603 OS disassembly


Post by jlvaldez » Mon Jan 20, 2020 2:47 am

NSFW wrote:I'm trying to get my head around the Sleigh language, which is how processor instructions are modeled for Ghidra's disassembler:

https://ghidra.re/courses/languages/html/sleigh.html

I still don't see how to test changes though. I copied Dzida's changes into my local Ghidra, but the CPU32 option doesn't appear. There's a "reload Sleigh" script, in Ghidra's script manager, but running it doesn't make any difference.

NSFW,
To get CPU32 to show up in my Ghidra, I had to compile it with sleigh via the command line. Once compiled, it would show up in sleigh after a reboot (though I didn't notice the refresh button). Once it shows up in sleigh, it looks like you can simply recompile it to make it use the new file.

Path is <Ghidra root>/support/

You'll see the sleigh and sleigh.bat files.

Input it seems to want is:
./sleigh -DBaseDir=<path to Ghidra root directory (one directory above the support directory)> -i ../Ghidra/Processors/68000/data/sleighArgs.txt ../Ghidra/Processors/68000/data/languages/CPU32.slaspec ../Ghidra/Processors/68000/data/languages/CPU32.sla

This is where my help ends. I don't understand the sleigh language, but I haven't spend too much time looking into it.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <

I had a quick look at the sleigh.bat file need to look further.