CSL '0401' Program Binary Disassembly Notes

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

[karter16]

Hello,
I'm trying to get Ghidra working for the CPU32 and having a few problems. Has anyone sucessfully got it running by following the instructions here?

>>> This project also relies on the following files which have been enhanced to add the appropriate CPU32 support (particularly the TBL lookup instructions).

Once Ghidra has been installed and the CPU32 support added the project files can be opened. <<<

The first problem I had was that 68000.sinc has many changes to be made and I wasn't going to do that manually - there must be some automated way to do it. Luckily I found a file called CPU32.zip in another forum which had almost all the required files. What it didn't have was CPU32.sla, so Ghidra complauned about that, does anyone know where to find it?

Finaly, when I tried to import the gar file that karter16 provided, the RESTORE is greyed out.

Hey Mark - Sent you a PM but realised given you're not at 10 posts I don't think you'll be able to reply to me - if you can view PM's then I've also flicked you my email address.

When I get home from work later I'll send you my exact setup with the CPU32 language files for Ghidra - I don't recall in enough detail what I did to give you advice without having my own config to hand. (will update the instructions at the same time to be clearer!). There's several other people who have got setup with this more recently, so if any of them chimes in you might get an answer sooner!

Re importing the GAR file I think you're on the right track, you just don't need to have a project created/open. You should be able to just open Ghidra and import the GAR file directly, the project is contained within the GAR file. That said it still won't work great until the CPU32 lang files are sorted.

Cheers,

Matt

[MarkD_M5]

Hello,
I'm trying to get Ghidra working for the CPU32 and having a few problems. Has anyone sucessfully got it running by following the instructions here?

>>> This project also relies on the following files which have been enhanced to add the appropriate CPU32 support (particularly the TBL lookup instructions).

Once Ghidra has been installed and the CPU32 support added the project files can be opened. <<<

The first problem I had was that 68000.sinc has many changes to be made and I wasn't going to do that manually - there must be some automated way to do it. Luckily I found a file called CPU32.zip in another forum which had almost all the required files. What it didn't have was CPU32.sla, so Ghidra complained about that, does anyone know where to find it?

Finaly, when I tried to import the gar file that karter16 provided, the RESTORE is greyed out.

Here are some of the errors I get when I try to import a binary file:

Errors compiling C:\Users\Mark D'Sylva\Documents\projects\customTuning\ghidra_11. 4.2_PUBLIC\Ghidra\Processors\68000\data\languages\ CPU32.slaspec -- please check log messages for details
ghidra.app.plugin.processors.sleigh.SleighExceptio n: Errors compiling C:\Users\Mark D'Sylva\Documents\projects\customTuning\ghidra_11. 4.2_PUBLIC\Ghidra\Processors\68000\data\languages\ CPU32.slaspec -- please check log messages for details
at ghidra.app.plugin.processors.sleigh.SleighLanguage .reloadLanguage(SleighLanguage.java:472)
at ghidra.app.plugin.processors.sleigh.SleighLanguage .initialize(SleighLanguage.java:139)
at ghidra.app.plugin.processors.sleigh.SleighLanguage .<init>(SleighLanguage.java:105)
at ghidra.app.plugin.processors.sleigh.SleighLanguage Provider.getLanguage(SleighLanguageProvider.java:1 33)
at ghidra.program.util.DefaultLanguageService$Languag eInfo.lambda$getLanguage$0(DefaultLanguageService. java:332)
at ghidra.util.task.TaskBuilder$TaskBuilderTask.run(T askBuilder.java:306)
at ghidra.util.task.Task.monitoredRun(Task.java:134)
at ghidra.util.task.TaskRunner.lambda$startTaskThread $0(TaskRunner.java:106)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1090)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:614)
at java.base/java.lang.Thread.run(Thread.java:1474)

---------------------------------------------------
Build Date: 2025-Aug-26 1351 EDT
Ghidra Version: 11.4.2
Java Home: C:\Program Files\Eclipse Adoptium\jdk-25.0.0.36-hotspot
JVM Version: Eclipse Adoptium 25
OS: Windows 11 10.0 amd64
Workstation: GTR7PRO

1	Can't read language spec C:\Users\Mark D'Sylva\Documents\projects\customTuning\ghidra_11. 4.2_PUBLIC\Ghidra\Processors\68000\data\languages\ CPU32.sla	Oct 05, 2025 04:17 PM
2	Loading language '68000:BE:32:CPU32' - Uncaught Exception: ghidra.app.plugin.processors.sleigh.SleighExceptio n: Errors compiling C:\Users\Mark D'Sylva\Documents\projects\customTuning\ghidra_11. 4.2_PUBLIC\Ghidra\Processors\68000\data\languages\ CPU32.slaspec -- please check log messages for details	Oct 05, 2025 04:17 PM
3	Can't read language spec C:\Users\Mark D'Sylva\Documents\projects\customTuning\ghidra_11. 4.2_PUBLIC\Ghidra\Processors\68000\data\languages\ CPU32.sla	Oct 05, 2025 04:17 PM
4	Error importing file: NORD_MST.bin	Oct 05, 2025 04:17 PM

Does anyone have any idea what I did incorrectly?

Thanks

[MarkD_M5]

Here's the function that calculates the variable speed lights based on oil temp. Useful to find this as these parameters are incorrectly mapped in the XDF.

Here's an earlier version of that function in C:

I've got almost the complete source code for MSS52, that's where this came from.

[karter16]

What year did the E46 M3 GTR come out?

It was a V8. I'm not sure which ECU it used though.

Also, which DME did the E39 M5 have, probably a previous generation MSS5x ECU.

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

[PistenPeter]

Update 16 September 2025:
The latest disassembly archive can be found here: https://github.com/karter16/CSL_0401...2025_09_16.gar

There is a lot of additional work been done since the March update - off the top of my head things like:

• CSL RF calculation path built out
• Operating System functions identified and built out
• SK (safety concept) self-test functions identified and built out
• A lot of the EEPROM read/write/test operations identified and built out
• CANBUS module identified and built out
• IPK functions identified and built out
• Timed tasks identified and built out

Top! Thanks for sharing!

[karter16]

Update 16 September 2025:
The latest disassembly archive can be found here: https://github.com/karter16/CSL_0401...2025_09_16.gar

There is a lot of additional work been done since the March update - off the top of my head things like:

• CSL RF calculation path built out
• Operating System functions identified and built out
• SK (safety concept) self-test functions identified and built out
• A lot of the EEPROM read/write/test operations identified and built out
• CANBUS module identified and built out
• IPK functions identified and built out
• Timed tasks identified and built out

[0-60motorsports]

Yep sure - will message you next week with some details.

Given you're on standard cams I do wonder whether this is actually tune related. As far as I know neither Bryson nor I see this problem on our tunes, both of which have had a lot of work down in the low RPM/partial load area. The CSL cams have quite different map/fuelling requirements to the standard cams, so it might be explained by something as simple as this. Anyway, some logging should help figure that out.

If this is happening for those with CSL cams then that's another matter.

Ok awesome! Take your time. Ive been living with this for years LOL. Thank you.