CSL '0401' Program Binary Disassembly Notes

[karter16]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

Thanks - great call out! Have amended :-)

[Bry5on]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

[karter16]

I've also uploaded an archive ghidra project which contains all my latest work - it can be found here: https://github.com/karter16/CSL_0401...2025_03_09.gar It's a work in progress and I keep on wanting to tidy it up more before sharing but if I do that I'll never share it. You'll just need to put up with the fact that some of my comments will be out of date and the inconsistencies of work in progress. Let me know if you have any Q's.

Again my ask would be if you figure things out that you post them here as you go so that I can keep incorporating discoveries into the master disassembly project.

[karter16]

I've written up a wiki page here: https://github.com/karter16/CSL_0401...works#overview which describes in detail how the MAP sensor is used to calculate RF. It includes explanation, details of all variables and parameters along with a full code listing and code walkthrough of the functions that calculate RF and the integral controller component.

If anyone has the time I'd really appreciate it if you could have a read through and review - my intent is that this should be a complete explanation of how the MAP sensor is used. It would be great as well if you have questions about how specific values are obtained (e.g. "how do I know that xyz really does what you say it does?") then please point these out and I can do detailed listings of those things as well. It's a bit hard to figure out what the appropriate bounds of this are as you can go to the n'th degree with everything. Ideally I'd like the end result to be something that is so clear and comprehensive it leaves no remaining doubt that this is indeed the way the MAP sensor works.

Random screenshots of the wiki page to snazz up this post.


Screenshot from overview


Screenshot from function description of rf_calc()


Screenshot from code walkthrough of rf_calc()


Screenshot from code walkthrough of rf_p_kad_i_calc()

[R3VM3UP]

Ah okay, that's the part I was missing, I don't think I've ever seen those posted anywhere. I was only aware of the 52_V508.A2L file.

[karter16]

Is there a specific reason why you have higher confidence that the 1801 XDF is more accurate?

Yeah in the same way the original XDFs were built off an 0901 A2L there is also an 1801 A2L.

Not sure if an 1801 XDF actually exists btw, if it does it's probably one that was built off the original 0901 work.


Sent from my iPhone using Tapatalk

[R3VM3UP]

Is there a specific reason why you have higher confidence that the 1801 XDF is more accurate?

[karter16]

Sorry for the massive quote, and forgive my ignorance on some of this, but are you just doing this all manually or have you developed some sort of scripts to handle this? I get it that you've got a fairly complete XDF for the 1801 binary, are you just looking up how variables defined in the 1801 XDF are being used in the 1801 decompiled binary, and then checking to make sure that they are being used in the same way in the decompiled 0401 binary?

No worries - the translation from 1801 to 0401 was manual. Previous efforts were scripted and resulted in about a 1 in 5 error rate. Which comes down to the way BMW managed the codebase and the way the compiler reorders variable name to memory address assignments. Doing this manually, in this case, results in a much lower error rate and also captured where memory locations have been repurposed, etc.


Sent from my iPhone using Tapatalk

[R3VM3UP]

bmwfnatic and I have been making a lot of progress, and that's culminated this weekend in me having the time to map across characteristics (Parameters, Curves and Maps) as well as Global Variables from the 1801 master binary to the 0401 master (I'm still to do the slave binary).

We've managed to map 973 global variables which I've listed here: https://github.com/karter16/CSL_0401...#master-binary



As well as all the characteristics from 1801 (except for things which don't apply to the CSL like HFM). There were 5 characteristics in the 1801 master binary I wasn't able to identify, plus another 115 that are specific to the 0401 binary. These 120 characteristics which are still to be identified are listed here: https://github.com/karter16/CSL_0401...#master-binary



I should be able to work out what a bunch of these are, I'm just focused first on getting in all the characteristics, etc. to both the Master and Slave so we can update the archive to share with others.


Side note - I found it interesting as I was going through the master binary to see that the EGAS module has a separate EGAS_WDK table for when the CSL snorkel flap is open which has some subtle differences in both the interpolation point and the values around the 1200 RPM mark - others are probably already aware of this but I hadn't come across it before:

Sorry for the massive quote, and forgive my ignorance on some of this, but are you just doing this all manually or have you developed some sort of scripts to handle this? I get it that you've got a fairly complete XDF for the 1801 binary, are you just looking up how variables defined in the 1801 XDF are being used in the 1801 decompiled binary, and then checking to make sure that they are being used in the same way in the decompiled 0401 binary?

On a similar note, as you find stuff, are you just manually labeling variables you find in the decompiled binary?

[karter16]

Is the C decompiler part of the disassembly tool?

Yep - the screenshots I've shared of C code are generated by the decompiler. The variable names and stuff need to be done by hand, but not having to manually convert all the ASM to C equivalent saves a lot of time. The decompiler isn't perfect so you need validate its output sometimes, but overall an awesome tool.


Sent from my iPhone using Tapatalk

[ac427]

Absolutely - things like the C decompiler (although not infallible) are a game changer for quickly understanding what's going on, I can understand ASM but no where near as easily as C.


Sent from my iPhone using Tapatalk

Is the C decompiler part of the disassembly tool?

[karter16]

It is satisfyingly fun to dig into all this 15-20 years later with the benefits of modern technology, I must say.

Absolutely - things like the C decompiler (although not infallible) are a game changer for quickly understanding what's going on, I can understand ASM but no where near as easily as C.


Sent from my iPhone using Tapatalk

[Bry5on]

You're most welcome - ask as many questions as you like. It's for the community's shared knowledge and interest that I'm doing this work. I certainly don't know all the answer and am just figuring it out as I go (I also can't guarantee I won't end up having to correct my own answers in the future!!!) but the whole point is to help us understand more.

Same, and we’re of course always subject to being wrong! In which case the community learning applies even better. It is satisfyingly fun to dig into all this 15-20 years later with the benefits of modern technology, I must say.

[karter16]

Thank you both for you help. It's really good to gain an understanding of not only how it works but the thinking behind it.

You're most welcome - ask as many questions as you like. It's for the community's shared knowledge and interest that I'm doing this work. I certainly don't know all the answer and am just figuring it out as I go (I also can't guarantee I won't end up having to correct my own answers in the future!!!) but the whole point is to help us understand more.

[ac427]

My data logs show that if you actually duct the lower snorkel to the bumper, you will have low IATs above 40mph. My theory is that the open top half of the flap actually allows air exchange, functioning as an exhaust when the lower half is supply. Just a guess based on my data logs with flap open/closed.

Also, it’s not just the IAT that’s right behind the radiator, but also the thermally conductive airbox itself (carbon should be a lot more conductive than plastic). Hot airbox could mean hot air at low speeds and loads, so it’s my opinion that the IAT is conservatively placed to prevent damage to the engine. If you’re concerned about the IAT readings, you’re WAY better off just ducting from the bumper to the airbox and actually having low IATs vs trying to spoof lower temps. I’ll get off the soap box now.

All good mate and thank you for the explanation.

yeah echoing this. I've had a look through 0401 and 1801. TAN is calculated exactly the same in both (e.g. there's no adjustment to the calculation of TAN itself in 0401), the KLs and KFs that take TAN as an input are also the same between both. The only difference is 0401 has additional code to utilize TAN in the calculation of RF based on MAP sensor and TAN. However as MpowerE36 has shown, the code implementation of the maths doesn't include any sort of "adjustment factor". Which further supports Bry5on's comment above. I think we can conclude doing it the way BMW did is a conservative approach. I would think as soon as you get some reasonable airflow through the box the IAT will be fairly accurate, and when you are sitting still (which isn't really the point of a CSL in BMW's eyes remember) the heat soak resultas in a conservative reading.

Thank you both for you help. It's really good to gain an understanding of not only how it works but the thinking behind it.