Karter16's Silbergrau E46 M3 Journal

[karter16]

This morning I removed the LHS radiator cowl. My objective with these modifications remember is that I retain the ability to return the car to stock. I therefore didn't want to cut-down or cut off the cowling. It was a quick job to detach the top radiator pipe and slide the cowling out.



Then right on cue the CSL oil dipstick tube showed up (along with the silver-coloured hardware I was waiting on for the airbox as well).



So I carried on going...

I didn't have a turkey baster for removing the SMG fluid from the reservoir, but I do have an abundance of my son's old enteral syringes and feed pump tubing :-)



All pretty straightforward - the little connector on the bottom at the back is a bit of a pain, but all done without too much fuss.




Next up will be a quick general clean up, as well as cleaning the ICV and throttle bodies (might as well while I'm in there) :-)

[karter16]

Yesterday afternoon I conditioned the intake boots and clamped them to the airbox. The tool for the Oetiker clamps works out at about $100NZD however you approach it so I saved $85 dollars by using the dremel to modify some standard $15 SuperCheapAuto clamp pliers.



This worked very nicely - I'll paint the pliers so they don't rust and they can go in the toolbox for next time.





I also installed 2x new rubber isolators - Being 20 years old the rubber in the current ones is probably soft and perishing.



Plans for between now and whenever the dipstick tube turns up is to remove the LHS radiator cowl shield in preparation for installing the airbox.

Yesterday I also took the car for a drive and logged the relevant variables with TestO to get a baseline capture before I go making any changes to the car. I want to make sure I'm as prepared as I can be for moving across to the 0401 program. To that end I will also be doing another full review of each change I've made to the partial as part of v1 of my tune. It's been long enough now since I did it that I should be able to do a good review of it and make sure I haven't made any mistakes.

[karter16]

Finally made it to my summer break! Did a quick fitment check of the airbox, filter and Haimus snorkel to make sure I don't get any surprises during install. I've noted others have found the hose attachments to be tight so am prepared that I might need to do some adjustments there like heinzboehmer did to get them to click in correctly.

The CSL dipstick tube is finally with the local courier for delivery, more than 6 months after I ordered it, so should get it in the next few days. The only other thing I'm waiting on is the silver replacement screws for the two halves of the airbox, but they aren't a blocker given I can use the ones the airbox came with and swap out easily later.

[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 :-)