CSL '0401' Program Binary Disassembly Notes

[karter16]

So I don't really have any particular use case for it right now, but I'm pretty confident I've worked out enough about the DS2 telegrams and how they are constructed in the DME, and then interpreted in TestO to be able to replace an existing telegram with any set of variables I like from the DME. I'll try to prove this out in the next few weeks with a simple example (I'm thinking I could make AQ_REL_ALPHA_N available in TestO as a demonstration - although this wouldn't actually really be useful as a general solution for the VE tuning as it will be much easier to create a modified version of heinzboehmer's spreadsheet that applies the interpolation factor to AQ_REL).

What are the limitations?
- Replacing an existing value with another value of the same size (byte, word, etc.) is no problem as it's simply replacing one memory address with another in the code.
- The DS2 telegrams tend to have room in them to insert additional values (array elements set to 0), but this is not as easy as a move instruction is 6 bytes vs a clr instruction at 2 bytes. It would mean greater modification to the code to jump out to another location would be required.
- Doing any of this means flashing a custom program binary. It also means while the DME is running the custom binary other DS2 tools (like INPA) won't read the modified values correctly.

Is there actually a use case for this?
I don't really know to be honest. Maybe other people can think of some useful examples? I'm more envisaging this as potentially being useful for testing/debugging/learning to expose variables that otherwise aren't exposed outside of the DME.

[karter16]

100% confirmed that the value exposed in TestO is AQ_REL. AQ_REL_ALPHA_N_PT_KORR is not exposed at all in TestO.

[karter16]

Okay - so I've categorically confirmed that the AQ_REL_ALPHA_N value which is used as the y axis in the CSL Alpha N map is NOT available over DS2. AQ_REL is available over DS2 as is AQ_REL_ALPHA_N_PT_KORR (on the DME side at least).

I'm 90% sure that it's AQ_REL that's exposed in TestO as "Relative Opening", which would make sense on pretty much every level, but I have a bit more work to go to be 100% confident in that.

Either way, it looks as though the VE tuning process can be made more accurate with the appropriate compensation for this.

[karter16]

I posted the below in the a quick and easy way to street tune your csl conversion for drivability thread, and thought I'd also put here for reference:


For what it's worth I've just been working through this in my disassembly project and thought it would be worth noting here. Below is a summary of how it comes together:

AQ_ABS (absolute cross-sectional opening) = AQ_ABS_LLS (absolute cross-sectional opening of idle control valve) + AQ_ABS_WDK (absolute cross-sectional opening of throttle plates)

AQ_REL (relative cross-sectional opening (%)) = (AQ_ABS - K_AQ_ABS_MIN (minimum possible cross-sectional opening)) / (K_QA_ABS_MAX (maximum possible cross-sectional opening) - K_AQ_ABS_MIN)

This AQ_REL value is what's used in the standard M3 software, a commonly referenced example of this is the VANOS maps - AQ_REL is the y-axis in those tables.


The important thing to know is that AQ_REL isn't used directly in the CSL AlphaN maps. It's actually a modified version of AQ_REL that is used.

For the purposes of this explanation I will call this modified value AQ_REL_ALPHA_N it is calculated thusly:

AQ_REL_ALPHA_N = AQ_REL / AQ_REL_ALPHA_N_FAKT

So what's AQ_REL_ALPHA_N_FAKT? It's just my name for the output of the lookup curve at: 0xE056




x axis is N (rpm) and the output is a scaling factor.

Essentially what this means is that AQ_REL_ALPHA_N will be a smaller value (between 0-30% smaller dependent on RPM) than actual AQ_REL beneath 2400 RPM.

Additionally there is another value that is also calculated in the same routine, let's call it AQ_REL_ALPHA_N_PT_KORR which is additionally scaled based on P_UMG (Ambient air pressure) and TAN (Intake air temperature).



This value isn't used in the CSL AlphaN maps (or in other operational code), but it is used in two routines which seem to be involved in the sending/export of data (I haven't figured out yet if these are the DS2 routines or something else). Crucially AQ_REL_ALPHA_N is NOT referenced in any sending/export routines. Which raises the possibility that the "Relative Opening" datapoint that we are logging in TestO isn't even the same data point that is actually used as an input to the VE table (indeed it could even be the standard AQ_REL variable). Looking at the two tables above they are normalized around 20 degrees C intake temp and ambient air pressure of 962mbar, so it's not going to be too far off either way, but for example today in Auckland was 1016mbar at 20C, so PRESUMING THIS IS THE CASE I'd be looking at a 4% variance.

I will spend more time looking at this to see if I can establish with certainty which of the two variables "Relative Opening" represents.


Also worth mentioning that the MAP sensor does not have any part in the calculation of AQ_REL. The MAP sensor is used in the calculation of air mass, which in turn is used in the calculation of final Relative Fill (an adjustment to the value obtained from the VE table).


I realize this post is more focused on the "academic" side but hopefully of use to the collective understanding.

[karter16]

Well being sick has given me the excuse to spend some more time working on the disassembly. I've been focused on the calculation of rg_m which is the mass of residual gas in the cylinder and is one of three components which results in the final calculation of mass of gas in the cylinder (which is key to the calculation of final RF).

I'm very pleased to have completely figured out the EVAN (intake cam) component of the calculation of rg_m. The position of the intake camshaft influences the amount of residual gas left in the cylinder. I've *almost* figured out the exhaust cam component of it as well, but am not quite there yet. I haven't yet figured out the units of the curves at 0xe6d6 and 0xe708 ( ppm008 if you're around I'd love a hint on these :-)).

Anyway - here's the intake component of the function. Once I've got the entire function figured out I'll do a write up and add it to the wiki page

I'm really pleased to have figured this out as MPowerE36's analysis hadn't gone in to this aspect of the mass calculation, and as far as I know no one has (publicly) figured this out.

[ac427]

Today I finally got round to trying setting k_rf_cfg to 0x02 (from 0x12) to take the MAP sensor out of the final RF calculation path.

The result is that the car behaves and drives in the same way as if the MAP sensor is physically disconnected. The car runs in AlphaN + TABG adjustment mode.

I didn't personally have any doubt that this would be the case (although I know others did), but good to prove this. I think I mentioned previously that it seems like this would be good practice to take the MAP sensor out of the RF calculation path when doing the VE tuning process. I can't think of an objective way to measure this though. If anyone has any ideas I'm all ears!

Me neither but it would be interesting to compare the VE tuning output from both with and without the MAP sensor tuning results.

[karter16]

What difference did you notice with k_rf_cfg to 0x02, poor part throttle performance?

Yep less responsive part throttle and more jerkiness. Exactly the same effect as disconnecting (electrically) the MAP sensor and going for a drive.

[ac427]

Today I finally got round to trying setting k_rf_cfg to 0x02 (from 0x12) to take the MAP sensor out of the final RF calculation path.

The result is that the car behaves and drives in the same way as if the MAP sensor is physically disconnected. The car runs in AlphaN + TABG adjustment mode.

I didn't personally have any doubt that this would be the case (although I know others did), but good to prove this. I think I mentioned previously that it seems like this would be good practice to take the MAP sensor out of the RF calculation path when doing the VE tuning process. I can't think of an objective way to measure this though. If anyone has any ideas I'm all ears!

What difference did you notice with k_rf_cfg to 0x02, poor part throttle performance?

[karter16]

Today I finally got round to trying setting k_rf_cfg to 0x02 (from 0x12) to take the MAP sensor out of the final RF calculation path.

The result is that the car behaves and drives in the same way as if the MAP sensor is physically disconnected. The car runs in AlphaN + TABG adjustment mode.

I didn't personally have any doubt that this would be the case (although I know others did), but good to prove this. I think I mentioned previously that it seems like this would be good practice to take the MAP sensor out of the RF calculation path when doing the VE tuning process. I can't think of an objective way to measure this though. If anyone has any ideas I'm all ears!

[karter16]

Continuing on with the MAP sensor work. I'll write this up properly and put it in the MAP sensor wiki, but for now here's the disassembled code listing. This is the function that takes the raw MAP sensor AD values from the ring buffer and calculates MAP pressure and manifold vacuum pressure.

It really would be very nice to have the actual parameter/variable names, but you'll have to suffer through my made up names (identified as all lowercase) :-)

Key things of note:
- The code loops through the ring buffer every time it runs and pulls and averages a number of valid samples (by default it's actually only 1 valid value that it samples).
- It then takes the raw value and offsets it and scales it according to the MAP scaler and offset parameters that have been known for some time.
- Manifold vacuum pressure is calculated as P_UMG (ambient pressure from the on-DME pressure sensor) minus MAP pressure.
- The function runs in both the segment task and the 10ms task.

[karter16]

This one is interesting. This (function at 0x00011e3c) is a debug function that runs in the background task. It tracks the time in milliseconds since the function last run and captures the longest time in DB_TBGND_MAX and the average in DB_TBGND_AV. This would have been useful during development as the BMW engineers were adding to the codebase to monitor the system and make sure that the CPU was getting to the background task regularly enough.

[karter16]

0x00ffeb36 is the 32 bit telegram from the MFL to the DME with the cruise control buttons status. This variable in turn is populated from the TPU config RAM (0x00ffff08) which is a shared RAM section between the DME and the TPU to allow transfer of data. The TPU facilitates the one-wire serial interface to the MFL.

Section 8.3.2 in 3.05 EGAS Safety Concept in the funktionsrahmen describes how this works and it seems that this is pretty much how it's implemented in the code as well. The safety concept code is really interesting to dig into and seems in general to be pretty close to how it's documented in the funktionsrahmen.

[karter16]

0x00ffe508 and 0x00ffe50a appear to be "total count of interrupts" and "number of interrupt service routines currently in progress" (note it is possible for this to be greater than 1 as a higher priority interrupt will "interrupt" a lower priority ISR) respectively.

I've named these "sys_interrupt_counter" and "sys_active_interrupts".

edit: renamed to sys_isr_count to mirror BMW's naming of CAN_ISR_COUNT

[karter16]

If anyone has any info about these 4 curves it would be super useful to know. From the code I I've worked through so far I *think* that 0xe708 and 0xe732 respectively are possibly representing molar mass of the residual gas mix based on camshaft position, but not overly confident about that yet.

[karter16]

These are all of the parameters from the master binary which we currently don't have the actual names for. For anyone who's wondering the addresses below are as the prog binary references them, so the actual addresses in the partial would be the value below minus 0x80000. e.g. 00088826 would be 0x8826.

00088826

00089840

00089a4c

0008a6c5

0008a97a

0008a97c

0008a97e

0008a9a2

0008a9a3

0008a9a4

0008a9a6

0008a9a8

0008a9aa

0008c354

0008c35a

0008c35c

0008c376

0008c378

0008c37a

0008c37b

0008c37c

0008c37e

0008c380

0008c382

0008c384

0008c3db

0008c558

0008c55a

0008c55c

0008c56c

0008c56e

0008c582

0008c59e

0008c5ba

0008c5e6

0008c682

0008d000

0008d002

0008d201

0008d202

0008d204

0008d205

0008d220

0008d222

0008d2ee

0008d2f0

0008d2f2

0008d2f4

0008d2f6

0008d2f8

0008d2fa

0008d2fc

0008d716

0008db30

0008df4a

0008dfac

0008e056

0008e088

0008e08a

0008e08c

0008e08d

0008e08e

0008e25c

0008e5e4

0008e5e8

0008e5ea

0008e5ec

0008e5ed

0008e5ee

0008e5f0

0008e5f2

0008e5fa

0008e5fc

0008e5fe

0008e600

0008e602

0008e604

0008e61e

0008e638

0008e69a

0008e69c

0008e69e

0008e6a0

0008e6a2

0008e6a4

0008e6c6

0008e6ce

0008e6d0

0008e6d2

0008e6d4

0008e6d6

0008e708

0008e732

0008e764

0008e7ae

0008e8fe

0008e918

0008e91a

And these are all the parameters from the slave binary which we currently don't have actual names for. I've included all the SMG parameters (0008a8xx to 0008aexx) which are missing actual names as well. Not sure if anyone has those, but thought I'd include them for completeness. To convert the below addresses to the offset in the partial it's what's below minus 0x88000. e.g. 0008808a would be 0x008a.

0008808a

0008903f

0008a1da

0008a1dc

0008a1de

0008a1df

0008a1e0

0008a1e2

0008a1e4

0008a1fa

0008a1fc

0008a1fe

0008a200

0008a202

0008a204

0008a206

0008a228

0008a24a

0008a24c

0008a24e

0008a251

0008a252

0008a253

0008a254

0008a255

0008a256

0008a258

0008a259

0008a25a

0008a25c

0008a25e

0008a260

0008a262

0008a263

0008a264

0008a265

0008a80e

0008a811

0008a814

0008a816

0008a817

0008a818

0008a819

0008a81a

0008a81b

0008a81c

0008a81e

0008a821

0008a824

0008a826

0008a82a

0008a82c

0008a830

0008a832

0008a838

0008a83c

0008a83d

0008a840

0008a842

0008a844

0008a846

0008a848

0008a84a

0008a84c

0008a850

0008a852

0008a853

0008a856

0008a85a

0008a85e

0008a860

0008a862

0008a865

0008a866

0008a867

0008a883

0008a88a

0008a88c

0008a88d

0008a896

0008a898

0008a89c

0008a89d

0008a8a2

0008a8b8

0008a8ba

0008a8c4

0008a8d4

0008a8e2

0008a918

0008a96e

0008a9a0

0008a9aa

0008a9b4

0008a9be

0008a9cc

0008a9da

0008aa30

0008aa44

0008aa52

0008aad2

0008aadc

0008aae4

0008aeb4

0008e706

0008e707