CSL '0401' Program Binary Disassembly Notes

[heinzboehmer]

I have no idea what scenario it's trying to mitigate. If someone wants to give it a go and report back on whether they can detect any difference that would be super cool.

Hmm, maybe this has something to do with setting the emissions readiness for the post cat O2s? Wild guess, but that's the first thing that came to mind when you mentioned steady state driving.

Also, just came back from my lunchtime test drive. Did it a little differently, mostly because I hadn't read your post before heading out

This is what I did:

1. Take car out for a spin without modifying anything in the tune. Made sure to hit redline in first, starting from 2500 rpm.
2. Set K_NOISE_CFG to 0x00, flash DME.
3. Repeat step 1.

I noticed zero difference, which makes complete sense based on your findings. My dreams of a secret burnout mode are crushed.

[karter16]

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.

It's worth noting that in the 1801 binary the parameters are different (3rd gear instead of 4th, and speed thresholds differ) so this has been tuned specifically for the CSL binary.

So it's super restricted. I have no idea what scenario it's trying to mitigate. If someone wants to give it a go and report back on whether they can detect any difference that would be super cool.

To validly test this.

Control test
1: Drive in 4th gear and maintain speed between 44 and 54 km/h (28-33 mph) for more than 3 seconds.
2: Boot it and monitor noise and acceleration. (bonus points for logging rather than going by feel)

Test
1: Turn noise control off by setting K_NOISE_CFG to 0x00.
2: Drive in 4th gear and maintain speed between 44 and 54 km/h (28-33 mph) for more than 3 seconds.
3: Boot it and monitor noise and acceleration. (bonus points for logging rather than going by feel)


Bry5on and heinzboehmer - with regard to limits at low speed/rpm it is worth noting that the DME DOES limit throttle plate opening below 3000 RPM. (I have no idea whether there's anything at all to be gained by making any change)

This is controlled by KF_EGAS_WDK (when CSL flap is closed) and kf_egas_wdk_ask (when CSL flap is open). Now I'm not suggesting that there's a whole bunch of torque hidden there or anything, and (if there is anything to be gained at all in terms of torque and/or noise) I would imagine that changes to this would require co-ordinated changes across timing, fueling, VANOS tables, etc. but there are a range of reasons the engineers might have done this and some of it might have been for noise control and for smoother application of torque.

Some tuners do make changes to this (interestingly some actually reduce the throttle plate opening further under 3000 rpm, I wonder what the reasoning for this is, or maybe it's to enhance the feeling of the car coming onto the power), although amusingly they do so only to KF_EGAS_WDK (after having lowered the CSL flap open threshold) so half the time the adjustments they've made aren't actually in effect. Given kf_egas_wdk_ask was only identified when I worked through the disassembly hunting the "CSL specific" parameters I would suspect they simply weren't aware that the table exists. The more I see of some tunes the more I do wonder how much they understand everything they're doing.

Please note: I am NOT in any way suggesting that I have the skills of a professional tuner or that I can do a better job than them. But simply reading some changes in the context of the disassembled code it does appear that people don't always actually understand what they changes they are making do and the effect that they do (or in this case don't) have.

[karter16]

I haven't worked through the logic end to end, but pretty sure this is quite limited compared to being a blanket suppression of max torque under 60kph, I think it's targeting only certain conditions, but let me work it through.

[heinzboehmer]

One of the torque limitations in the Moment Manager is to restrict maximum torque below a certain vehicle speed under certain conditions in order to quote "reduce noise". I've seen others edit this out by adjusting KL_MD_BEGR_NOISE to not have restricted torque below 60 km/h.

Dude what

Disabling this is the first thing I'm doing tomorrow before my test drive, now that the car is finally back together.

[Bry5on]

Well I’m definitely going to be disabling this now that modern tires are grippier. That’s an extra 50ft-lbs in first gear! Here we go.

Also, this would be a cool thing to have enabled/disabled based on sport mode. Wonder why they didn’t do that.

[bmwfnatic]

You mean I’ve only had 80% torque in first gear this whole time?! Ha

My E60 M5 6spd did the same thing, ign based torque management, I disabled it and it turned my description of the car from “quite civil” to a “burnout machine”…

[Bry5on]

You mean I’ve only had 80% torque in first gear this whole time?! Ha

punched this in to ChatGPT for fun. It immediately figured out this is a noise management routine for a car

START noise_st_calc
|
|-- Is speed in mid range AND correct gear selected AND motor is active?
| |
| |-- YES --> Add time since last check to "valid condition timer"
| |
| |-- NO -->
| |
| |-- Is speed out of bounds OR wrong gear AND noise mode is not active?
| |
| |-- YES --> Reset "valid condition timer" to 0
|
|-- Is:
| - throttle/power demand high enough
| - speed in valid range
| - correct gear selected
| - "valid condition timer" exceeds required threshold?
| |
| |-- YES --> Set noise mode to ACTIVE (set high bit)
|
|-- Is:
| - noise mode currently ACTIVE
| AND
| - throttle is too low OR wrong gear selected OR speed out of acceptable range?
| |
| |-- YES --> Deactivate noise mode (clear high bit) AND reset timer
|
|-- Save current system time as "last checked time"
|
|-- Is noise mode INACTIVE OR noise feature is DISABLED in configuration?
| |
| |-- YES --> Clear low bits (0 and 1) of noise state
|
| |-- NO --> Noise is ACTIVE AND config is enabled:
| |
| |-- Is "mode bit 0" enabled in config?
| | |
| | |-- YES --> Set bit 0 in noise state
| |
| |-- Is "mode bit 1" enabled in config?
| |
| |-- YES --> Set bit 1 in noise state AND RETURN
|
RETURN

[karter16]

Random aside.

One of the torque limitations in the Moment Manager is to restrict maximum torque below a certain vehicle speed under certain conditions in order to quote "reduce noise". I've seen others edit this out by adjusting KL_MD_BEGR_NOISE to not have restricted torque below 60 km/h.



Worth noting that if you want to turn this off completely you can simply set K_NOISE_CFG to 0.






Other notes:
- If you set bit 0 of K_NOISE_CFG to 1 you can make the car use the VANOS noise tables.

[Bry5on]

If you guys had to reduce that list by 2 bytes what would you drop? Lambda Integrator 2? (I only say that cause like Heinz I've found bank 1 runs consistently slightly leaner than bank 2 so I only really need to use Lambda 1)

Yep!

[karter16]

If you guys had to reduce that list by 2 bytes what would you drop? Lambda Integrator 2? (I only say that cause like Heinz I've found bank 1 runs consistently slightly leaner than bank 2 so I only really need to use Lambda 1)

[karter16]

Don’t have to do this by hand, if you can get a compiler going for this arch you can just write it in C, compile as a single function without runtimes and copy the assembly from the compiled program.

I'd still need to map the various memory locations for the compiler somehow though right? (e.g. stack location, locations of the global variables, etc., plus tell it what values were already in what registers, etc.). Also if the compiler doesn't have an understanding of the memory map and where the function is going to go in memory space it's not necessarily going to get things like near and far jumps right, etc. I'd have thought?

[bmwfnatic]

Don't want to make it seem simpler than it is. That's still over 100 instructions to craft by hand (no assembler, no ability to use labels, etc.) and then debug by hand. It's a lot of work, but it does seem as though it should be achievable.

Don’t have to do this by hand, if you can get a compiler going for this arch you can just write it in C, compile as a single function without runtimes and copy the assembly from the compiled program.

[heinzboehmer]

You have more confidence in my assembly (actually it's not even going to be assembly really, more like poking machine code directly into the ROM) programming skills than I do myself haha. But yes, I was thinking about this further and I think that the safety concept implementation probably does mitigate a fair amount of the risk actually. I think provided I only change the Master section of the ROM then we can be pretty confident that the Slave will identify scenarios where the Master is non-performant and reset it and log a code. It hadn't occurred to me last night that all critical safety functions are maintained in parallel by both processors. I'll still do some more investigation into this but from a safety perspective even if there was some edge case bug in the modified code the Slave should maintain the function of the DME from a safety perspective.

I would 100% put my DME at risk to try this sort of thing out. Thing has been through WAY worse. There's a couple jumper wires hanging out in there cause I've destroyed some pads with so much soldering/desoldering.

But I totally get it, distributing this kind of stuff is scary. Almost as scary as the assembly itself, ha.


Also, I think Bryson covered everything. I'm essentially logging the exact same things.

[karter16]

Okay cool - TKA it is.

The more I look at this the simpler it seems to be getting. Slight change in approach to that proposed above.

Turns out there actually IS some space to add a pointer in the array to another CAN function. It looks like it's full but actually repeats several times for ARBID 0x513 (which is the last one in the array) so I could slot an additional one in there. The advantage of that is that I could then use the existing CAN_Send_DME_ARBID() function to call the new one as well (less messing around making sure I've set the stack correctly before jumping to the new function, etc.).

This then means that the actual coding boils down to the following:

1: Create a copy of CAN_Send_DME_ARBIDs() in empty ROM space - ~ 30 instructions.
2: Reference the new function in the 10ms task - 1 instruction.
3: Create a new function that handles the new CAN message in empty ROM space - ~ 80 instructions (based on the function for ARBID 0x316).

This would of course be for a simple version with fixed variables. Abstracting out the ability to configure what variables to push would be significantly more work.

Don't want to make it seem simpler than it is. That's still over 100 instructions to craft by hand (no assembler, no ability to use labels, etc.) and then debug by hand. It's a lot of work, but it does seem as though it should be achievable.

[Bry5on]

Awesome thanks!

Intake Air Temp = TAN byte on Master @ 0x00FFEDD9
Radiator Temp - do you want coolant temp (TMOT byte on Master @ 0x00FFEDDA) or radiator outlet temp (TKA byte on Master @ 0x00FFEDDE)?
EGT = TABG word on slave but available on DPR @ 0x00FF8088
Relative Opening = AQ_REL word on slave but available on DPR @ 0x00FF80DE or AQ_REL_ALPHA_N word on Master @ 0x00FE97A depending on what you want to use it for.
Lambda Integrator 1 = LA_F_REGLER1 word on Slave but available on DPR @ 0x00FF80CA
Lambda Integrator 2 = LA_F_REGLER2 word on Slave but available on DPR @ 0x00FF80CC

All of these are available either from the Master CPU or are already available on the Dual-Ported RAM which is convenient.





You have more confidence in my assembly programming skills than I do myself haha. But yes, I was thinking about this further and I think that the safety concept implementation probably does mitigate a fair amount of the risk actually. I think provided I only change the Master section of the ROM then we can be pretty confident that the Slave will identify scenarios where the Master is non-performant and reset it and log a code. It hadn't occurred to me last night that all critical safety functions are maintained in parallel by both processors. I'll still do some more investigation into this but from a safety perspective even if there was some edge case bug in the modified code the Slave should maintain the function of the DME from a safety perspective.

I think TMOT is already available on CAN ID 0x329 but radiator outlet temp is not. So, radiator outlet temp

Relative opening would be for part throttle tuning, or IDing where in the map you are for any given condition. Nice that they're all generally available!

For completeness, here are some of the other things I log..

CAN ID 0x316:
- Engine Speed
- Torque command

CAN ID 0x329:
- Cruise control buttons
- Coolant temp
- Ambient pressure
- TPS
- Clutch/Neutral status

CAN ID 0x545:
- Cruise active status
- Oil temp
- Oil level

CAN ID 0x153 (from DSC):
- Speedo
- Brake status (binary on/off, not pressure)
- DSC status
- DSC intervention status
- DSC commanded throttle cuts

CAN ID 0x615 (from cluster):
- Ambient temp
- Displayed Speed
- Night lighting status (thanks Heinz)

CAN ID 0x1F3 (from DSC):
- Lateral acceleration
- Longitudinal acceleration
- Yaw rate

CAN ID 0x1F5 (from steering angle sensor):
- Steering angle