CSL '0401' Program Binary Disassembly Notes

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

[karter16]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

Thanks - great call out! Have amended :-)

[Bry5on]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

[karter16]

I've also uploaded an archive ghidra project which contains all my latest work - it can be found here: https://github.com/karter16/CSL_0401...2025_03_09.gar It's a work in progress and I keep on wanting to tidy it up more before sharing but if I do that I'll never share it. You'll just need to put up with the fact that some of my comments will be out of date and the inconsistencies of work in progress. Let me know if you have any Q's.

Again my ask would be if you figure things out that you post them here as you go so that I can keep incorporating discoveries into the master disassembly project.