Karter16's Silbergrau E46 M3 Journal

[Slideways]

Haha well it might not be the entire binary but I will be sharing everything I do figure out. I find it crazy that after 20 years there isn't more information available around the MSS54 and how it works. I do appreciate people who put the effort in on stuff like this often want some return for their efforts so it makes sense perhaps. Anyway I certainly don't want to make money out of this or gatekeep anything I figure out, so will absolutely be sharing for the benefit of the community.


Sent from my iPhone using Tapatalk

There was a massive thread on M3F which had a lot of disassembly stuff in it, but that got lost with the old forum.

You've probably seen the new thread, but it is a fraction of what it once was - https://nam3forum.com/forums/forum/s...me-information

[karter16]

Excellent work! Looking forward to the complete c style disassembly that you're gonna share with all of us

Haha well it might not be the entire binary but I will be sharing everything I do figure out. I find it crazy that after 20 years there isn't more information available around the MSS54 and how it works. I do appreciate people who put the effort in on stuff like this often want some return for their efforts so it makes sense perhaps. Anyway I certainly don't want to make money out of this or gatekeep anything I figure out, so will absolutely be sharing for the benefit of the community.


Sent from my iPhone using Tapatalk

[heinzboehmer]

Excellent work! Looking forward to the complete c style disassembly that you're gonna share with all of us

[karter16]

Well I've made some excellent progress this evening in item 2 on my list. I've located the series of routines that calculate ignition timing and have mostly figured out the routine that retrieves values from the maps I'm interested in understanding. The below is a C-style reasonable-equivalent of the assembly code. In this I've added comments as I've figured bits out and have managed to give my own names to most of the local and global variables involved.




The key thing of interest I've uncovered is confirmation that use of the KF_TZ_GRUND, KF_TZ_LL and KF_TZ_VL maps are mutually exclusive based on operating mode. I'm pleased to have confirmed this as there is some ambiguity on the matter depending on where on the internet you look and this greatly aids in my understanding of blending the M3 and CSL maps. Secondly I now have the addresses of where the global variables TMOT, RPM and Relative Fill are stored. Given these are commonly used variables knowing what they are will be useful in further understanding the code.

Next is to continue to follow the chain of TZ (ignition) related routines to understand the rest of them. From a quick look the next function appears to overlay adjustments from the MomentManager in response to signals from ASC/DSC.

[karter16]

Well I feel like a bit of a muppet but I've figured out the memory reference issue - it's a very simple reason and I should have realised sooner..

The MSS54HP has 2x processors operating in a Master/Slave arrangement. The full binary that I'm ingesting has the individual binaries for the master and slave conjoined together. The issue with this is that both Master and Slave have the parameter space at 0x00008000 - 0x0000ffff. This is then mapped to virtual location 0x00088000. FOR BOTH PROCESSORS.

What I was missing was that when loading and disassembling the binary as a whole, the code on both the master and slave were together referencing the same 8000 bytes between 0x00088000 and 0x0008ffff. What made this tricky to spot is that the full binary for the Master is 0x80000 bytes long, so the virtual offset aligned perfectly to the offset of the start of the slave binary plus the 0x8000 physical offset of the slave's parameter space in the binary. It made it appear as though the references to the slave parameter space was just fine.

Anyway, the solution is to simply split the binary in two, ingest them both separately into Ghidra and offset the 0x00008000-0x0000ffff memory space to 0x00088000 for both.

On and I've also labeled all of the memory locations used by the Internal Register Map which shows me where the code is accessing things like the QADC, CTM4, QSM, TPU, etc. which will further help to identify what various functions are doing.

In loosely related news the CSL dipstick tube finally shipped today so I should have it in time for the Christmas break :-)

Onwards and upwards.

[Bry5on]

Love this! Excited to hear what revelations you find. It’s been more than a decade since I’ve poked around with the MSS54HP disassembly. Keep us posted! Especially if you find interesting things with DSC interventions between normal and sport modes

[karter16]

A couple of things have been playing on the back of my mind while I've been working on CSL tune file.

1: Confirming that the lookup tables are definitely linear interpolated - Given the MC68336/376 has the CPU32 TBL instructions built in it would make sense, but it would be nice to see it with my own eyes.
2: Identifying exactly how some of the ignition/injection maps are utilised in the program.

I decided the best way to figure this out would be to do some disassembly of the full (program) binary. After a number of sessions playing around learning Ghidra (and adding the CPU32 instruction set to Ghidra) I've managed to confirm #1.

I've found the Curve/Table lookup functions in the program code and confirmed their use for things like interpolating between VANOS table values (Below is a snippet of part of one of the lookup functions).



I don't think there was ever really that much doubt that this wouldn't be the case, but it's good to know for sure. Having identified the lookup functions in the code means that I can now use them to look "backwards" to their calling functions and more easily identify where the various tables are used. This leads into #2 on my list which is to identify the functions that use tables like KF_TZ_LL so that I can see exactly how those tables are used and how they influence the final calculated ignition timing (the draft FunktionsRahmen floating around is unfortunately not complete in this regard).

The current problem I have is that the data space (which holds the contents of the partial binary) is split into to sections in the memory space. The lower half of the partial (addresses 0x0000-0x7FFF as you would read them in TunerPro) is at offset 0x88000 and the upper half (0x8000 - 0xFFFF) is at 0x8000. Ghidra is linking references to the lower half (so with the offset 0x88000 - 0x8FFFF) just fine, however it is not for the upper half (0x8000 - 0xFFFF). I suspect that this is probably because when BMW compiled the original code the assembler has used relative offsets for accessing the low memory as doing so is more efficient that using calls that are capable of accessing high memory. This makes perfect sense from an efficiency perspective, but makes it difficult when it comes to disassembly.

I simply need to spend some more time working through this.

Why do all this? Just because it helps reduce the room for error if I better understand exactly how the maps are used. I might also discover something new/useful along the way that might be helpful knowledge for the community. Also my 3 year old was up at 4am and there's only so many things you can do in the middle of the night when the rest of your family is asleep :-)

[Slideways]

Dammit no I hadn't - don't know why I had it in my head I'd seen someone else do this. Thanks very much for that - have ordered some suitable hardware. FYI what's needed are M6x16 Torx washer head screws.

There was a post a while back where NZ_M3 ordered a BMW bolt in that size to mimic the CSL hardware. Unfortunately, those are zinc coated (not A2 stainless). They also need to be put through a die to clean the threads and the finish is similar to the exhaust bolts that bolt section 1 to 2.

[karter16]

Not sure if you have tried them yet, but the 07119905016 bolts won't work on the Karb airbox.

Dammit no I hadn't - don't know why I had it in my head I'd seen someone else do this. Thanks very much for that - have ordered some suitable hardware. FYI what's needed are M6x16 Torx washer head screws.

[Slideways]

Not sure if you have tried them yet, but the 07119905016 bolts won't work on the Karb airbox.

[karter16]

Some of the bits of hardware I was waiting on for the airbox install arrived today.

07119905016 - original silver bolts that hold the two pieces of the airbox together. The black ones that come with the Karbonius look great, but I'm wanting to replicate the original CSL look with the silver hardware.

07119901780 - original bolts that attach the snorkel to the airbox. The Haimus Racing snorkel comes with silver through-bolts and nuts, plus insertable collars to go in the 3D-printed mounting holes. I'm not sure whether the Haimus Racing airbox doesn't have threaded mounts on the airbox, but anyway the Karbonius does. I did a quick test fit and confirmed that using the Haimus collars with the OE bolts works.

07119902626 - original bolts for the MAP sensor to secondary air rail. As George Hill noted some time ago these are too short to fit on my MAP sensor adapter, but with them in hand I was able to confirm that these are DIN7984 spec bolts, and have ordered some M6x18mm DIN7984 bolts which will fit perfectly.

Only item (I think) I'm waiting on now is the CSL dipstick tube. I realised I have a bit of a problem when I went downstairs to find something and couldn't even remember what's in all of the boxes of parts on my shelves. Need the Christmas break to come round so that I can get some of this stuff installed!

[karter16]

Well look what arrived yesterday, less than 6 weeks after I ordered it! I saw a few months ago that Karbonius had made another mold for the CSL replica airbox to speed up production and certainly would seem to have helped!

Can't really say anything about this piece that hasn't already been said. It's spectacularly good. The memory of the cost simply melts away when you hold it in your hand and look at it.

I'm still waiting on the CSL dipstick tube plus a few minor pieces of hardware, but hopeful of having everything by the time the Christmas break rolls around!

In the meantime all these parts continue to clutter up my spare room!

[Bry5on]

It appears you are correct. I checked back in my excel files and indeed they do look the same. Not sure where I got that from..

[karter16]

KF_TIENDE_N_RF are different between euro and CSL tunes that I’m looking at.

Interesting - so the original binary from my car is 211323001901JD54 (appears to be an unlisted variant in the Comprehensive MSS54/MSS54HP DME Information thread) and KF_TIENDE_N_RF is the same as for the 0401PD31 binary.


1901JD54


0401PD31 (CSL)

[Bry5on]

I'm curious - aside from KF_TI_N_RF (which I missed out of the list in my post above) the only other Injection/Ignition tables I see differences in are in the warm-up/cat heating/secondary air pump tables for calculating the warm up factors (which I'll not bother with for now).

I do note that in the US map KF_RF_N_AQ_REL and KF_TIENDE_N_RF differ to the CSL map, however these two are the same between my Euro tune and the CSL tune.

Or I'm missing something 😅

I didn’t modify KF_RF_N_AQ_REL and KF_TIENDE_N_RF are different between euro and CSL tunes that I’m looking at. Just a couple notes