CSL '0401' Program Binary Disassembly Notes

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

[karter16]

I have neither but I can get them off you can give me please. I have standard cams, or CSL intake setup with CSL MAP sensor and full SS V1 catless resonated full exhaust system. SMG too.

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.

[0-60motorsports]

Sure - I'm away from my laptop for the next few days, so let me come back to you on a test scenario. What logging options do you have available? TestO or similar?

Also are you running CSL cams or standard cams?

I have neither but I can get them off you can give me please. I have standard cams, or CSL intake setup with CSL MAP sensor and full SS V1 catless resonated full exhaust system. SMG too.

[karter16]

If you tell me How to log it I can try. My car always does it

Sure - I'm away from my laptop for the next few days, so let me come back to you on a test scenario. What logging options do you have available? TestO or similar?

Also are you running CSL cams or standard cams?

[0-60motorsports]

Separate things. What I've addressed is specific to the Terra modified binary. If it affects the standard CSL binary as well it's not related to this.

Would be great to capture the behavior on logging as that would help narrow it down. Bit hard as as far as I'm aware I can't reproduce it on my car.


Sent from my iPhone using Tapatalk

If you tell me How to log it I can try. My car always does it

[karter16]

Separate things. What I've addressed is specific to the Terra modified binary. If it affects the standard CSL binary as well it's not related to this.

Would be great to capture the behavior on logging as that would help narrow it down. Bit hard as as far as I'm aware I can't reproduce it on my car.


Sent from my iPhone using Tapatalk