CSL '0401' Program Binary Disassembly Notes

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

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

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

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

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

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

[SliM3]

Hey - it's a short doc but 8.02 in the funktionsrahmen explains it https://github.com/karter16/CSL_0401...mic%20Lead.pdf

Essentially RF can be adjusted for knock protection or cylinder pressure management. The integral component is suspended while this is in effect, so that it doesn't try to “adjust out” the dynamic adjustment.


Sent from my iPhone using Tapatalk

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

[karter16]

Really light on details of the Jag sadly.

Here's what it looks like (not much has changed in the past four years except for stable mates): https://youtu.be/UGBo-wUDK4g

And a few details here, although I wasn't as great about updates. Not having the details was part of what motivated me to make this wagon build thread: https://www.jaguarforums.com/forum/x...roject-184994/

Absolutely gorgeous! Very cool


Sent from my iPhone using Tapatalk

[karter16]

karter16 I've probably missed but is "rf dynamics" explained anywhere?

Hey - it's a short doc but 8.02 in the funktionsrahmen explains it https://github.com/karter16/CSL_0401...mic%20Lead.pdf

Essentially RF can be adjusted for knock protection or cylinder pressure management. The integral component is suspended while this is in effect, so that it doesn't try to “adjust out” the dynamic adjustment.


Sent from my iPhone using Tapatalk

[ac427]

karter16 I've probably missed but is "rf dynamics" explained anywhere?

[Bry5on]

Do you happen to have a build thread somewhere for the Jag? I would love to read it if it exists.

Really light on details of the Jag sadly.

Here's what it looks like (not much has changed in the past four years except for stable mates): https://youtu.be/UGBo-wUDK4g

And a few details here, although I wasn't as great about updates. Not having the details was part of what motivated me to make this wagon build thread: https://www.jaguarforums.com/forum/x...roject-184994/

[karter16]

In my other car.

Do you happen to have a build thread somewhere for the Jag? I would love to read it if it exists.

[karter16]

This is brilliant. I'm still working on absorbing your written description and browsing through your project simultaneously to make sense of how you arrived at it, but writing it out like that is extremely helpful.

Another dumb question, when building a project like this did you have to populate the memory map in Ghidra or is that done automatically based on selecting the 68k architecture? I'm assuming you did, based on the nomenclature used for the memory segments.

Nice one - yeah it takes a while to get the hang of how the program works as a whole and then it all starts to make more sense.

Yeah we had to populate the memory map manually. There's lots of different ways to configure the 68k memory so it was built out based on the work others have done in the past, referring to the Motorola documentation, etc. It's fairly crucial to get it right as the disassembler takes the memory map into account when disassembling (e.g. if you leave program ROM marked as writable you are in for a bad time with pointer references lol because the disassembler has to assume anything could change at any time.)

[R3VM3UP]

This is brilliant. I'm still working on absorbing your written description and browsing through your project simultaneously to make sense of how you arrived at it, but writing it out like that is extremely helpful.

Another dumb question, when building a project like this did you have to populate the memory map in Ghidra or is that done automatically based on selecting the 68k architecture? I'm assuming you did, based on the nomenclature used for the memory segments.