CSL '0401' Program Binary Disassembly Notes

[Bry5on]

So it looks like the 0x03+ message format is the same for both IDs 0x700 and 0x701

For Byte 0
bits 0-2: cylinder ID (0x700 only reports 001, 010, 011 and 0x700 only reports 100, 101, 110 as expected)
bit 3: no function (for MSS54/HP, this is probably used in the V8 M5 though to ID cylinder 8)
bit 4: knock detected (1 for knock detected)
bit 5: no function identified yet. Could be related to bit 4 with a type of knock detection state.
bits 6 and 7: some sort of evaluation state. So far I only see values of 11 and 00, where the transition happens after cranking the engine. Probably ‘engine running’ or something similar.

I have a datalog recorded that I’ll need to parse tonight to evaluate the other Bytes.

I’ve also flashed a new file to my car with some extra ignition advance to see if I can trip some knock.

[karter16]

Awesome thanks for that - I haven't had a chance to go through the log you sent in detail yet, but what you've posted there makes sense. The frame is exactly the same for either bank, just bank 1 sent on 0x700 and bank 2 on 0x701.

Will be super interesting to see what you get if you can cause some knock. As I mentioned I *think* that byte 1 is the amount of retardation being applied for the cylinder - will be interested to see what you get.

[karter16]

Came across the OBD2 readiness monitor functions today:

This function passes a pointer to obd_check_monitor(). The pointer points to an array of bytes which list the DTCs that are applicable to the monitor in question. The DTCs are evaluated against stored status and the monitor status (ready or not) is returned.

[karter16]

I've now figured out 128 of the 138 parameters specific to the CSL. You'll see that my naming conventions aren't entirely consistent, but once I've figured out the last 10 and have a complete view I can then align the naming accordingly.

[ac427]

I've now figured out 128 of the 138 parameters specific to the CSL. You'll see that my naming conventions aren't entirely consistent, but once I've figured out the last 10 and have a complete view I can then align the naming accordingly.

Excellent work mate 👍

[karter16]

Well I hate to think how many hours I've spent on this in the last 9 months but this evening I figured out and named the last of the 138 CSL specific parameters.

The last one was the parameter that defines how long the sport button needs to be held down for to trigger displaying the oil level sensor readout on the dash. The function that does this is schalt_m_st_calc (Master CPU "switches" status byte). The function runs every 10ms therefore a hex value of 0x64 (decimal 100) means that by default the button needs to be held down for 1 second.




I might have names for all 138 parameters but the job doesn't finish here. I'm still in the middle of tidying up, refining and aligning names. Once that's done I then need to add/refine the descriptions of the parameters (Edit: this is the most important bit. Over the last 9 months I've got pretty good at understanding obscure German abbreviations for technical terms, but I need to make sure this ends up being something others can reference and use without the backstory), configure conversion factors, etc.

Nevertheless this is a pretty big milestone and I have to say I've managed to get an awful lot further than I was expecting when I embarked on this.

[Bry5on]

Well I hate to think how many hours I've spent on this in the last 9 months but this evening I figured out and named the last of the 138 CSL specific parameters.

The last one was the parameter that defines how long the sport button needs to be held down for to trigger displaying the oil level sensor readout on the dash. The function that does this is schalt_m_st_calc (Master CPU "switches" status byte). The function runs every 10ms therefore a hex value of 0x64 (decimal 100) means that by default the button needs to be held down for 1 second.




I might have names for all 138 parameters but the job doesn't finish here. I'm still in the middle of tidying up, refining and aligning names. Once that's done I then need to add/refine the descriptions of the parameters (Edit: this is the most important bit. Over the last 9 months I've got pretty good at understanding obscure German abbreviations for technical terms, but I need to make sure this ends up being something others can reference and use without the backstory), configure conversion factors, etc.

Nevertheless this is a pretty big milestone and I have to say I've managed to get an awful lot further than I was expecting when I embarked on this.

Legendary work my friend

[karter16]

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!

Finally coming back to this:

The code looks like this:





Setting k_ask_zustand_cfg to 0x06 will force the flap to open as soon as RPM goes above 1000 and it will stay open until RPM goes below 800. So effectively open all the time except at idle.

This seems on the face of it that it could be an easier way to set the flap to "always" be open. However looking at the code you'll note that setting k_ask_zustand_cfg to 0x06 also skips checks for KATH_ST, etc. which has the effect of opening the snorkel flap even during warm up. This in turn has the effect, because of the way the code is written, of not blending the kf_egas_wdk_kh table during warm up, rather the DME will pull straight from the kf_egas_wdk_ask (CSL flap) table.



This appears to be the only side effect. The AlphaN tables are fine because they are blended based on AVAN1_SOLL_FAKTOR as discussed previously, and the adder table is blended in based on flap status (e.g. it's added on top of the standard map or the KATH map depending on which one is active).

Given the effect of the egas_wdk tables I think it's probably best to continue with the approach of adjusting the flap open rpm tables rather than changing k_ask_zustand_cfg in order to avoid the undesirable side effect of the kf_egas_wdk_kh table being ignored during cold start/warm up.

[Tomba]

Great work Karter, I have been reading this for a while and would like to have the skills to do this as well. Thanks for sharing all this.

Okay so this is very limited.

Essentially what it does is monitor for the condition where the car is in 4th gear and has been cruising between 44 and 54 km/h for more than 3 seconds. At that point it enters "noise" mode where the max requestable torque is limited. As soon a different gear is selected or the car drops below 44 km/h or goes about 70 km/h noise mode ends....

For European markets there is a noise measurement around 50km/h and then full load. Similar function is in my 2010 S1000RR which closes the exhaust valve to reduce noise during this event.
Depended if you reach the engine speed limiter at the end of the test track or other conditions is in which gear you need to start. I believe the Ferrari 360 Modena would reach the limiter in 2nd gear and therefore the test conditions were adjusted.

[karter16]

Depended if you reach the engine speed limiter at the end of the test track or other conditions is in which gear you need to start.

That would quite possible explain then why the "NOISE_GANG" for the CSL is 4th gear, but for the Euro M3 it's 3rd. Maybe the extra power + reduced weight of the CSL was enough to cause the starting gear to be different.

Thanks for this - very interesting!!

[0-60motorsports]

Karter. Amazing work. Thanks for doing this. Hopefully now we can have an OE+ kind of tune for the community to use with our different OG mods like CSL intakes and SS exhaust systems.

[sda2]

As I said earlier, awesome work! Did you go through the SMG CAN implementation by any chance? It would be awesome to ditch the SMG and install DCT or 8HP with a CanTCU, but for that the secondary CAN bus needs to be deciphered.

Afaik the MSS54 acts as a gateway between the gearbox and the chassis, so the can11h message "EGS1" on 0x43F is actually sent out by the DME, not the SMG control unit.

SMG CAN starts at something like 0x410 up to 0x412. I think olza also posted about this.

[SliM3]

As I said earlier, awesome work! Did you go through the SMG CAN implementation by any chance? It would be awesome to ditch the SMG and install DCT or 8HP with a CanTCU, but for that the secondary CAN bus needs to be deciphered.

Afaik the MSS54 acts as a gateway between the gearbox and the chassis, so the can11h message "EGS1" on 0x43F is actually sent out by the DME, not the SMG control unit.

SMG CAN starts at something like 0x410 up to 0x412. I think olza also posted about this.

You'll be better off running a MaxxEcu for 8HP control. Copy the optimal torque map from whatever OEM SW you want (I use CSL) and overwrite the MaxxEcu base tq map + increase values by 28-30%. Plus you can program CAN outputs for a “stock-like” gear position indicator to replace the SMG display that's currently in our clusters.





Sent from my iPhone using Tapatalk

[0-60motorsports]

You'll be better off running a MaxxEcu for 8HP control. Copy the optimal torque map from whatever OEM SW you want (I use CSL) and overwrite the MaxxEcu base tq map + increase values by 28-30%. Plus you can program CAN outputs for a “stock-like” gear position indicator to replace the SMG display that's currently in our clusters.





Sent from my iPhone using Tapatalk

Ma man! Can't wait to see it!

[karter16]

You'll be better off running a MaxxEcu for 8HP control. Copy the optimal torque map from whatever OEM SW you want (I use CSL) and overwrite the MaxxEcu base tq map + increase values by 28-30%. Plus you can program CAN outputs for a “stock-like” gear position indicator to replace the SMG display that's currently in our clusters.
Sent from my iPhone using Tapatalk

Very cool - is this an in-flight project you're working on?