CSL '0401' Program Binary Disassembly Notes

[karter16]

Don't rely too heavily on that funktionsrahmen as it is not accurate!

Yeah definitely - it's riddled with inaccuracies/additions that have been made in code after that version of the funktionsrahmen was written. Have found it useful though to explain some of the concepts / thinking behind various modules that you can then match up (or not) to what's in the code.


Sent from my iPhone using Tapatalk

[sda2]

Awesome work! Its nice to see more people diving into this. I have some IDA disassemblies of MSS54 from the CAN bus analysis, I dig them out and send them to you, maybe its of use for you.

Would you be fine with me linking this thread or the Github page on MS4X.net?

[karter16]

Awesome work! Its nice to see more people diving into this. I have some IDA disassemblies of MSS54 from the CAN bus analysis, I dig them out and send them to you, maybe its of use for you.

Would you be fine with me linking this thread or the Github page on MS4X.net?

That would be awesome thanks! The more we share the better! Yes please feel free to link to either or!


Sent from my iPhone using Tapatalk

[karter16]

I haven't posted any updates in a few days but have been making some progress.

One of the key components of MpowerE36's work is the calculation of what he terms m_720_map, which is the calculated air mass per 720 degrees of crankshaft rotation. It's the main component of the calculation of RF from MAP.

as he identifies the calculation of m_720_map looks like this:

m_720_map = m_720_1 - m_720_2 - m_720_3

Now m_720_1 is calculated air mass based on the MAP sensor reading and nominal air pressure and temperature - that's the baseline if you will.

m_720_2 is a compensation for pressure loss in the system (due to TETV (tank ventilation) and the like).

m_720_3 Mpower_E36 has identified as "air mass correction per 720 degrees of crankshaft rotation" and referred to the table at 0xe42c - it looks like this:



Now the thing is, by default 0401 doesn't use this table. If we look at the segment task we see (in part):



k_rg_m_cfg's (my name) value is 1 in 0401:



So by default two functions are called. the second of these (what I've called rg_m_calc()) provides a calculated value for MpowerE36's m_720_3.

And when I look through this function it is calculating a mass value based on things like intake and exhaust camshaft position, tabg (there are an entire separate set of tabg calculation functions solely for informing this function), etc.

Now why would we need to know camshaft position and exhaust gas temperature? Because what m_720_3 is is the calculation of the mass of residual exhaust gas left in the cylinder (which varies, especially, based on cam overlap). Remember the DME intentionally recirculates some exhaust gas (particularly at certain RPM and loads) to reduce emissions and we can see this playing out in the table above (which isn't used by default, but gives us a representation of what the system is doing).

Anyway - I have some more work to do to finish up documenting the interpretation of this function, but pleased to have figured this out and have a more concrete understanding of exactly what it is.

[karter16]

I've renamed the function "calculate_pressure_from_air_mass()" in my previous post to "p_egbp_calc()" given, as I've been working through everything, I've identified that this function is looking up a value for exhaust gas back pressure.

This is the function with parameter and variable names that make sense:



The function looks up a curve which provides an estimated value of exhaust gas back pressure based on current ML (air mass flow).

This value is relative (e.g. it's just the back pressure component). so this is then added to P_UMG_FILTER (ambient air pressure) to get an absolute exhaust gas back pressure measurement.

This value is filtered through a PT1 filter and then checked for max/min values for plausibility, before returning.

Here's what the parameters look like:




The calculated value p_egbp is then used in the calculation of rg_m.

[karter16]

I'm continuing to make good progress. I've now understood and named about 70 of the 112-odd CSL specific parameters. The names are of course my best guess as to what they would logically be named based on what I can figure out from BMW's naming convention. Unless anyone who has access to the actual names of these parameters is willing to share then my made-up names will have to do :-)

There's about 40 more parameters which I'm still working through to establish their purpose and what they should be called, but I'm very pleased with how it's going. I'm categorizing as I go (as can be seen in the screenshot below), which shows the modules which contain changes for 0401.

[ac427]

I'm continuing to make good progress. I've now understood and named about 70 of the 112-odd CSL specific parameters. The names are of course my best guess as to what they would logically be named based on what I can figure out from BMW's naming convention. Unless anyone who has access to the actual names of these parameters is willing to share then my made-up names will have to do :-)

There's about 40 more parameters which I'm still working through to establish their purpose and what they should be called, but I'm very pleased with how it's going. I'm categorizing as I go (as can be seen in the screenshot below), which shows the modules which contain changes for 0401.

Great work as always mate.

[ppm008]

8a980 KL_TANM_PT1_INIT
8e5f4 K_RF_DIAG_F_KATH
8e5f6 K_RF_DIAG_F_VAN
8e5f8 K_RF_DIAG_SCHWELLE
8e848 KF_RF_KORR_DRREL
8e6c8 K_RG_R
8e6ca K_RG_V_HUB
8e6cc K_RG_ZYLANZ_BANK

[karter16]

8a980 KL_TANM_PT1_INIT
8e5f4 K_RF_DIAG_F_KATH
8e5f6 K_RF_DIAG_F_VAN
8e5f8 K_RF_DIAG_SCHWELLE
8e848 KF_RF_KORR_DRREL
8e6c8 K_RG_R
8e6ca K_RG_V_HUB
8e6cc K_RG_ZYLANZ_BANK

Amazing - thank you so so much!


Sent from my iPhone using Tapatalk

[karter16]

ppm008 really appreciate your help - any chance I could list out all the parameter addresses I'm working on and see if you've got details for any others? I've come up with names for a bunch but if it's possible to confirm the actual names that would be even more ideal. (don't want to bug you too much though so feel free to say no!)

[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

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

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]

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]

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.