CSL '0401' Program Binary Disassembly Notes

[karter16]

Makes sense, which binary do we use for this?

Off the back of Heinz's suggestion I'm setting up a GitHub repo with the basics to enable multiple people to contribute to this. I'll share here as soon as it's good enough to share as a start. This will include the binary, etc (I'm using Terra's modified 0401 binary)


Sent from my iPhone using Tapatalk

[bmwfnatic]

Off the back of Heinz's suggestion I'm setting up a GitHub repo with the basics to enable multiple people to contribute to this. I'll share here as soon as it's good enough to share as a start. This will include the binary, etc (I'm using Terra's modified 0401 binary)


Sent from my iPhone using Tapatalk

Sounds good, but I meant more which binary belongs to the A2L.
I understand we intend to reverse the CSL bin.

[karter16]

Sounds good, but I meant more which binary belongs to the A2L.
I understand we intend to reverse the CSL bin.

Ah I'm with you apologies - afaik there was never a correct A2L leaked for the CSL binary - others have pieced it together from the A2L that was leaked. It is incomplete and there are a range of parameters/curves and tables that seem specific to the CSL that are not identified by the A2L. This is part of the fun and as I'm going through I'm discovering where the XDF/A2L is incorrect.


Sent from my iPhone using Tapatalk

[bmwfnatic]

Ah I'm with you apologies - afaik there was never a correct A2L leaked for the CSL binary - others have pieced it together from the A2L that was leaked. It is incomplete and there are a range of parameters/curves and tables that seem specific to the CSL that are not identified by the A2L. This is part of the fun and as I'm going through I'm discovering where the XDF/A2L is incorrect.


Sent from my iPhone using Tapatalk

I know there isn’t one for the CSL binary, I am still trying to figure out which binary it does belong to 😂

[karter16]

I know there isn't one for the CSL binary, I am still trying to figure out which binary it does belong to 😂

This is why I shouldn't reply to comments at work. Sorry. Yes interesting question - I haven't seen that information anywhere. I guess a way to do it would be to load each binary against it and see how much of it aligns, but that would be a huge amount of effort. Also I guess it's entirely possible the A2L is from during development and doesn't align exactly to any production binary.


Sent from my iPhone using Tapatalk

[karter16]

Original post is now updated with link to the GitHub repo and some basic information on getting started. For anyone who is interested please have a look and let me know where you might need more info/guidance on getting up and running.

[karter16]

It appears that the memory space at 0x00ff8000 through 0x00ff87ff (which is managed by CS5 in the SIM module) is somehow a shared memory space between Master and Slave for global variables which need to be accessed by both functions that reside on the master and on the slave. I'm yet to confirm for sure or figure out exactly how it works, or whether there's some other mechanism at play.

[Niklas]

Nice work, the next consequent step would be to advance or reroute the SMG-CAN-functionality (or PT-CAN) to deal with the E92 and/or F8x DCT.

[karter16]

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.

[bmwfnatic]

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.

Seems it's just a bit shifted, 0 starts earlier and there are 6.
At the bottom of function 0x1ddfc there seems to be some logic where the old amount of activated lights is compared against a new hypothetical value, and once this new value has been consistent for at least K_DWF_T_HYS (0xac7b) amount of times, the new value is adpoted.
This is to prevent the lights from going back on and off if the temperature is on the edge I think.

[S54B32]

It appears that the memory space at 0x00ff8000 through 0x00ff87ff (which is managed by CS5 in the SIM module) is somehow a shared memory space between Master and Slave for global variables which need to be accessed by both functions that reside on the master and on the slave. I'm yet to confirm for sure or figure out exactly how it works, or whether there's some other mechanism at play.

This could be a reason, why I never really got a emulator to work in one of the eeproms. The emulator doesn't support writing from ecu side to it.

[karter16]

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:

[Bry5on]

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:

That's interesting. The CSL flap in factory software is never open under 1600rpm. This situation should only occur in an error state where the flap is stuck open. Or you've modified the binary to open earlier of course.

[karter16]

Repo is now updated with known global variables (1179) for the Slave binary, as well as unknown characteristics (104) for the slave as well.

[karter16]

Well it was an arduous job but I now have a "complete" 0401 XDF built out. I had to make well north of 500 changes/additions/deletions to the public 0401 XDF. The automated process that was used a few years ago to generate the XDF was impressive, but still seems to have had an error rate of about 20% or so.

Below is the process I've followed for building this out:

1: Build out 1801 disassembly
2: Compare SMG characteristics and code between 0901 and 1801 to map across the characteristics that can be.
3: Map 1801 disassembly across to 0401 (I sighted every variable/characteristic individually in context to ensure it was mapped correctly, any that I couldn't verify have been marked as unknown)
4: Take the publicly available 0401 XDF
5: Run comparison on the XDF against symbols from 0401 disassembly
6: Add/Update/Delete from XDF as necessary

Is this 100% accurate? Certainly not! I did this by hand and I have undoubtedly made errors along the way. That said the error rate should be about a 20th of what it was before.

The XDF now identifies unknown characteristics that are referenced in the code, so although we don't know everything about them we can see that they exist and what we do know.

What next? I need to do some tidy up on the layout, unfortunately it's a manual job to re-order the characteristics in the XDF and they're not in sequential order because others who have built out the public xdd in the past have used the "insert at this point" feature, which overrides the default of placing the item in the right location.

Interestingly I came across a not insignificant number of items which had been manually corrected by others in the past but which were in fact still incorrect. It is not enough to look at the order/placement of the parameters against a known version, you have to actually compare at the line-by-line code level to be sure you are mapping the parameters correctly as BMW have inserted/removed items in the middle of the lists of parameters (rather than adding at the end in all cases) between versions.


As soon as I have things tidied up I'll share the XDF here.