Karter16's Silbergrau E46 M3 Journal

[karter16]

I've spun up a thread (https://nam3forum.com/forums/forum/s...assembly-notes) in the Coding section which I will keep updated as I work through the disassembly. Aim is to make the info easy to find and also splits it out from this build thread.

[karter16]

I've been going through the public XDF for the 0401 binary and sorting out some of the incorrect references. They're usually pretty easy to confirm by looking at whether the data makes sense. This one made me chuckle 😛

[karter16]

Today I cleaned up the top front RACP points and sprayed with the e-coat matched enamel I have.

First up I masked the area around the mount (photo taken prior to clean up).



Then I used a ziploc bag as a miniature spray booth by taping it to both the RACP and the spray can. I also made sure to cover/block every other hole/exit point in the RACP so I didn't get any over spray wafting out anywhere.




And the end result (paint is still wet here):




I have some clean up to do on a few rust spots on the seat bench, but will do this once I have the A08 in hand and can touch it up properly.

At this point though the front mounts are ready for the installation of the brace (drilling and tapping will be done at the time of installation of the brace as I need to take the subframe off to tap the threads.

[karter16]

Got a few bits and pieces done this weekend.

On Saturday morning dad and I welded up the cracks in the top of the front right RACP mount. As usual I did a bad job of taking photos as we went, but I did get a couple here and there.

As a recap, this is what the front right looks like from the top:



As you can see in the photo above the crack coming down towards the bottom of the photo is hidden behind the rear seat sheet layer. So that we could see how far this crack went we inspected the bottom side of the top layer of the RACP with my boroscope.



As can be seen the crack extends just to the point that the RACP bends down to layer up with the rear seat sheet. For reference the threaded insert visible on the right hand side of the image is for the seatbelt buckle.

Knowing how far down the crack extended meant that I was easily able to cut the small section of the seat layer out so that we could access the end of the crack to drill and weld. We found that a rounded nose carbide burr in the die grinder was the best way to clean up the surface around the cracks.



Dad then MIG welded the cracks up - I unfortunately didn't get any photos of this as I was running extraction and lighting while dad welded. A couple of comments though:

- We used some ceramic fibre insulation segments to pack the RACP cavity to prevent sparks, grindings, etc. from traveling inside the cavity. the ceramic fiber insulation is good in that it's non-flammable.
- I had previously measured the thickness of the RACP layers to be welded and dad had obtained some equivalent sheet metal to run some trials on and dial in the settings on the MIG.
- We went slow to avoid heating everything up too much, even so the cavity wax on the underside of the top RACP layer tends to melt and smoke along where you've welded, good extraction is advised.
- We used the boroscope again to check the other side of the welds (where they are on a single layer of sheet) and confirm good penetration of the weld.

With the welding done I then cleaned up the top surface with the carbide burr to level out the welds and leave an, as flat as possible, surface for the brace to mount to.

I unfortunately didn't get any photos of the welds prior to cleaning up and putting a protective layer of undercoat on.




As you can see the surface is not perfectly smooth (the flash from the phone actually makes it look more pronounced than it is in reality - it is less than 1mm, which will be perfectly fine for this situation. The OE welds stick up a couple of mm anyway. I didn't want to take away too much material at any point with the burr, so played it safe and left a small amount of extra material in place.

You may also notice that we welded the little cutout that we made to access the end of the crack back in place and smoothed it out with a little body filler. Not really necessary given it's going to spend the rest of its life under the seat again, but for the sake of an extra 20 minutes work it's worth it in my opinion.

I hand painted on the under coat as I wanted to make sure I could get it into all of the corners well, there's not a lot of room in there to rotate a spray can. I'll do another layer of undercoat, and then sand it back a little, mask up, build myself a little spray booth inside the car and do a couple of coats with the e-coat matched enamel I have. I'll then dust on some A08 on the seat bench (when I can finally get some, whole other story) to replicate the original surface as much as possible.


Secondly the DIN7984 hex head bolts for the MAP sensor arrived, they're identical to the original items except 18mm long to address the greater thickness of the 101 sensor mounting point, plus they're stainless rather than the zinc-coated original bolts. I'm happy with how these have turned out:

[karter16]

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

Yes I remember perusing the old thread many years ago. Such a shame it was lost 😭

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