CSL '0401' Program Binary Disassembly Notes

[S54B32]

I've been looking into the calculation of RF (relative fill) and how the MAP sensor etc. inputs into that, as it still seems to be an area of debate.

From what I've seen so far the following misconceptions that float around can be addressed:

Misconception 1: "The MAP sensor isn't used in normal use, the CSL runs pure AlphaN
This is absolutely not the case, this may be due to a misinterpretation around how the status byte at 0x00ff807e is calculated, however in the happy path flow of the software the MAP sensor input is absolutely used (the difference between manifold pressure and ambient pressure is used to calculate an RF adjustment value). The amount of input it has appears to be limited to part throttle applications in low and mid-range RPM (hello drivability), but to say that the CSL runs pure AlphaN just isn't true (sorry AlphaN crew 😬)

Misconception 2: "The MAP sensor is only used as a backup when there is a TPS sensor failure"
Again as above, this isn't the case. The MAP sensor certainly IS used as a back up for various purposes including approximating RF when TPS input is implausible. It's also used (when the engine isn't running) to capture a p_umg replacement value if the DME onboard pressure sensor is in error state.


And this leads on to the most interesting of these misconceptions...

Misconception 3: "The MAP sensor input is limited in the code to a max 2.5% adjustment factor"
This one isn't wrong, so much as it's only part of the whole picture. It is true that in the function that calculates the RF adjustment as a result of pressure difference (it does this by taking the difference of final RF and RF calculated from pressure (p_umg - MAP_Pressure)) there are limits applied to the resultant rf adjustment to a max of 2.5 percentage points up and down. However the key thing that seems to have been missed is that the final RF value that it references to calculate the new RF pressure adjustment IS the pressure-adjusted value from the previous time the function ran. The function runs in the 10ms task, which means in the space of 100ms RF can be adjusted up down by up to 25 percentage points as a result of MAP sensor input. This isn't a limiting factor it's a smoothing factor.


So what does this mean? In short, the MAP sensor is used to provide a pressure adjusted RF value which is used under part throttle conditions. The application of this pressure adjustment is smoothed to a maximum rate of change of 2.5% of max RF per 10ms.

I'm VERY happy that finally someone spends the time to bust this myth. Thank you for contributing this to the community!
Just for all the skeptical persons out there, could you please share some screenshots of the relevant parts of the disassambly to make your findings about this bulletproof?

[heinzboehmer]

However the key thing that seems to have been missed is that the final RF value that it references to calculate the new RF pressure adjustment IS the pressure-adjusted value from the previous time the function ran. The function runs in the 10ms task, which means in the space of 100ms RF can be adjusted up down by up to 25 percentage points as a result of MAP sensor input. This isn't a limiting factor it's a smoothing factor.

This is some amazing insight. I hadn't seen this piece of info before. Thanks for sharing!

[karter16]

I've been looking into the calculation of RF (relative fill) and how the MAP sensor etc. inputs into that, as it still seems to be an area of debate.

From what I've seen so far the following misconceptions that float around can be addressed:

Misconception 1: "The MAP sensor isn't used in normal use, the CSL runs pure AlphaN"
This is absolutely not the case, this may be due to a misinterpretation around how the status byte at 0x00ff807e is calculated, however in the happy path flow of the software the MAP sensor input is absolutely used (the difference between manifold pressure and ambient pressure is used to calculate an RF adjustment value). The amount of input it has appears to be limited to part throttle applications in low and mid-range RPM (hello drivability), but to say that the CSL runs pure AlphaN just isn't true (sorry AlphaN crew 😬)

Misconception 2: "The MAP sensor is only used as a backup when there is a TPS sensor failure"
Again as above, this isn't the case. The MAP sensor certainly IS used as a back up for various purposes including approximating RF when TPS input is implausible. It's also used (when the engine isn't running) to capture a p_umg replacement value if the DME onboard pressure sensor is in error state.


And this leads on to the most interesting of these misconceptions...

EDIT: I've adjusted two sentences in the below which were partially incorrect.

Misconception 3: "The MAP sensor input is limited in the code to a max 2.5% adjustment factor"
This one isn't wrong, so much as it's only part of the whole picture. It is true that in the function that calculates the RF adjustment as a result of pressure difference (it does this by taking the difference of final RF and RF calculated from pressure (p_umg - MAP_Pressure)) there are limits applied to the resultant rf adjustment to a max of 2.5 percentage points up and down. However the key thing that seems to have been missed is that the final RF value that it references to calculate the new RF pressure adjustment IS the pressure-adjusted (via ML) value from the previous time the function ran. This isn't a limiting factor it's a smoothing factor.


So what does this mean? In short, the MAP sensor is used to provide a pressure adjusted RF value which is used under part throttle conditions. The application of this pressure adjustment is smoothed to a maximum rate of change.

[karter16]

Spent a little bit of time working through the 10ms task in the master binary to figure out what each of the functions it calls does. There's several still to work out but have made some pretty good progress. I've also figured out the inter-processor monitoring of the system timers and the EGAS Safety Concept Program Execution Control mechanism, as well as confirmed via the funktionsrahmen that the MSS54 uses dual-ported RAM to share variables between the two processors for non-critical purposes (which confirms my previous suspicion that that RAM space is shared). Also found in that same document that for sharing of variables for critical functions the IPK (inter processor communication) system is used. I'll try to find that mechanism in the code as well as would be useful to understand how it works.

[karter16]

Could condition 3 be SMG launch mode?

Yes I believe it is (at least the first half of the condition is) I haven't quite worked out the "Schalten" (Shifting) bit - I'm not quite sure why that's included/why it needs to be. Does that mean every time the gearbox is "Shifting" the flap qualifies to be open? That bit doesn't seem quite right, so maybe "Schalten" means something a little bit different?

Edit: bmwfnatic has confirmed that in context "Schalten" is definitely "while shifting" - he suggests that this is possibly to pre-empt the situation where downshifting brings RPM etc. above the threshold so the flap is preemptively opened for the "blip". This seems like a logical explanation for this condition.

[ac427]

So I've been thinking about this and decided to have more of a look into it to see if I can figure out why BMW would go to the trouble for such a small variation.

I have been going through the function that determines the opening/closing of the flap and it turns out there actually more to it when it comes to deciding whether the flap should be open or closed. There are a range of different conditions that can contribute to the flap being opened.

Condition 1: Engine Speed (RPM) is greater than the FlapOpen RPM from the FlapOpen(Comfort/Sport depending) (this is the one we're expecting) plus a hysteresis value AND ML (air mass) is greater than a minimum value (20 kg/hr by default in 0401).
OR
Condition 2: Engine Speed (RPM) is 800rpm or greater AND a config parameter (0xA1DF is set to decimal 6 (it's 1 by default in the 0401 tune))
OR
Condition 3: SMG is in launch control mode OR SMG is "Schalten" (Shifting?)

Against all of these there is an additional condition that Ambient temperature must be above 3 degrees C or so (presuming I did the value conversion right).

So the flap open WDK table looks to be there for the launch control situation in production code, plus whatever the A1DF parameter does.

The same function also contains additional logic in the event that 0xA1DF is set to decimal 6. I haven't worked through this code yet to see exactly how that piece all works and whether setting the flap always open is as simple as setting 0xA1DF to 6.

Could condition 3 be SMG launch mode?

[Bry5on]

So I've been thinking about this and decided to have more of a look into it to see if I can figure out why BMW would go to the trouble for such a small variation.

I have been going through the function that determines the opening/closing of the flap and it turns out there actually more to it when it comes to deciding whether the flap should be open or closed. There are a range of different conditions that can contribute to the flap being opened.

Condition 1: Engine Speed (RPM) is greater than the FlapOpen RPM from the FlapOpen(Comfort/Sport depending) (this is the one we're expecting) plus a hysteresis value AND ML (air mass) is greater than a minimum value (20 kg/hr by default in 0401).
OR
Condition 2: Engine Speed (RPM) is 800rpm or greater AND a config parameter (0xA1DF is set to decimal 6 (it's 1 by default in the 0401 tune))
OR
Condition 3: SMG is in launch control mode OR SMG is "Schalten" (Shifting?)

Against all of these there is an additional condition that Ambient temperature must be above 3 degrees C or so (presuming I did the value conversion right).

So the flap open WDK table looks to be there for the launch control situation in production code, plus whatever the A1DF parameter does.

The same function also contains additional logic in the event that 0xA1DF is set to decimal 6. I haven't worked through this code yet to see exactly how that piece all works and whether setting the flap always open is as simple as setting 0xA1DF to 6.

Oh man that’s super interesting. Like a secret raw mode. Interested to hear what you find as you dig in more. This might be easier to set to 6 than setting every flap open engine speed for those that don’t have the flap installed. Thank you for all this work!

[karter16]

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.

So I've been thinking about this and decided to have more of a look into it to see if I can figure out why BMW would go to the trouble for such a small variation.

I have been going through the function that determines the opening/closing of the flap and it turns out there actually more to it when it comes to deciding whether the flap should be open or closed. There are a range of different conditions that can contribute to the flap being opened.

Condition 1: Engine Speed (RPM) is greater than the FlapOpen RPM from the FlapOpen(Comfort/Sport depending) (this is the one we're expecting) plus a hysteresis value AND ML (air mass) is greater than a minimum value (20 kg/hr by default in 0401).
OR
Condition 2: Engine Speed (RPM) is 800rpm or greater AND a config parameter (0xA1DF is set to decimal 6 (it's 1 by default in the 0401 tune))
OR
Condition 3: SMG is in launch control mode OR SMG is "Schalten" (Shifting?)

Against all of these there is an additional condition that Ambient temperature must be above 3 degrees C or so (presuming I did the value conversion right).

So the flap open WDK table looks to be there for the launch control situation in production code, plus whatever the A1DF parameter does.

The same function also contains additional logic in the event that 0xA1DF is set to decimal 6. I haven't worked through this code yet to see exactly how that piece all works and whether setting the flap always open is as simple as setting 0xA1DF to 6.

[karter16]

karter16 Top man. Thank you for your selfless devotion undertaking this mammoth task.

❤️ lots of credit goes to bmwfnatic as well - wouldn't have been able to do all this without him. And of course to those who have done all the work on the earlier XDF, etc. It's a community effort :-)


Sent from my iPhone using Tapatalk

[ac427]

karter16 and bmwfnatic thank you both your selfless devotion undertaking this mammoth task.

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

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

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

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:

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