CSL '0401' Program Binary Disassembly Notes

[karter16]

awesome! let me know tomorrow if there's anything else I can do to help figure those out :-)

[Bry5on]

Okay - so all are served as per DS2 with the exception of TABG as you note.

TAN (Intake Air Temp): correct - subtract 48
TKA (Radiator Outlet Temp): correct - subtract 48
TABG (Exhaust Gas Temp): correct - leave as is, DS2 divides by 16 to fit this into a byte instead of a word.
AQ_REL (Relative Opening): multiply by 0.003051757
LA_F_REGLER1 (Lambda Integrator 1): multiply by 0.000030517

Let me know if this works :-)

Beautiful. Thank you again my friend. Will test lambda integrator in the morning as it looks like I got the others sorted .. well, close on relative opening

[karter16]

Okay - so all are served as per DS2 with the exception of TABG as you note.

TAN (Intake Air Temp): correct - subtract 48
TKA (Radiator Outlet Temp): correct - subtract 48
TABG (Exhaust Gas Temp): correct - leave as is, DS2 divides by 16 to fit this into a byte instead of a word.
AQ_REL (Relative Opening): multiply by 0.003051757
LA_F_REGLER1 (Lambda Integrator 1): multiply by 0.000030517

Let me know if this works :-)

[karter16]

I'm so stoked too! Looks like it's outputting:
Intake Air Temp and Radiator temp: subtract 48, just like DS2 message
EGT: basically leave as-is, unlike DS2 message (multiply DS2 by 16)
Relative Opening: not sure yet, some scalar that looks the same as DS2. DS2 multiply by .0030518
Lambda Integrator: Subtract 2^15 then multiply by some factor that I'm not sure yet

https://datazap.me/u/bry5on/karter-can-logs?log=0&data=13-14-15-25-26-34&solo=15-17&mark=905

Awesome! I've got the config from TestO with the conversion factors so will dig those out shortly


Sent from my iPhone using Tapatalk

[Bry5on]

Yes! It is very satisfying to see that log!!! I'm so stoked that this has worked out!

It's a good proof of the general approach for making such changes as well.


Sent from my iPhone using Tapatalk

I'm so stoked too! Looks like it's outputting:
Intake Air Temp and Radiator temp: subtract 48, just like DS2 message
EGT: basically leave as-is, unlike DS2 message (multiply DS2 by 16)
Relative Opening: not sure yet, some scalar that looks the same as DS2. DS2 multiply by .0030518
Lambda Integrator: Subtract 2^15 then multiply by some factor that I'm not sure yet

https://datazap.me/u/bry5on/karter-can-logs?log=0&data=13-14-15-25-26-34&solo=15-17&mark=905

[karter16]

Yes! It is very satisfying to see that log!!! I'm so stoked that this has worked out!

It's a good proof of the general approach for making such changes as well.


Sent from my iPhone using Tapatalk

[Bry5on]

I flashed the modified program to the DME this morning and good news, I didn't brick the DME. Even better news, I found the bug!

As soon as I turned the ignition on after flashing I knew something was up as the DSC light was going mad. Modules relying on outbound CAN were throwing errors. It was a silly mistake to make that can be seen in the code above. I was trying to set the 17th frame in a 15 frame table..... 🤦♂️ Anyway, relocated the new CAN message to the unused 13th frame and refreshed. outbound CAN appears to now be working, all modules are error free and I used INPA to watch live CAN data coming in to the MK60 so the existing messages appear to be working without error.

Without being setup to log CAN data that's as far as I can take it, so the binary is now with Bry5on to do some further testing when he gets the chance and to see if the new message is being transmitted and if there's good data on it.

From there it will be a case of running with the modified program for a while and making sure that there isn't anything funny going on or any intermittent issues, etc. This is putting a small amount of additional load on the DME and is making the CAN bus busier, so we'll need to monitor and make sure there are no transient issues or less apparent bugs.

Exciting progress though!

My god the man has done it!! karter16 you are an absolute legend. Time to load this into the datalogger!

[karter16]

I flashed the modified program to the DME this morning and good news, I didn't brick the DME. Even better news, I found the bug!

As soon as I turned the ignition on after flashing I knew something was up as the DSC light was going mad. Modules relying on outbound CAN were throwing errors. It was a silly mistake to make that can be seen in the code above. I was trying to set the 17th frame in a 15 frame table..... 🤦♂️ Anyway, relocated the new CAN message to the unused 13th frame and refreshed. outbound CAN appears to now be working, all modules are error free and I used INPA to watch live CAN data coming in to the MK60 so the existing messages appear to be working without error.

Without being setup to log CAN data that's as far as I can take it, so the binary is now with Bry5on to do some further testing when he gets the chance and to see if the new message is being transmitted and if there's good data on it.

From there it will be a case of running with the modified program for a while and making sure that there isn't anything funny going on or any intermittent issues, etc. This is putting a small amount of additional load on the DME and is making the CAN bus busier, so we'll need to monitor and make sure there are no transient issues or less apparent bugs.

Exciting progress though!

[liam821]

I'm a bit concerned that I wrote the machine code for the new functions and haven't found any issues whatsoever with that work since. Usually that just means that you haven't found the bug yet 😏

That's generally how I feel after I've spent all day coding a giant function and it compiles without issue the first time...suspicious...

With that said, amazing work on decompiling the DME. This is very exciting work you're doing.

[Bry5on]

This is absolutely epic. Ready when you are my man! It’s been a while since I’ve done a regular full binary flash (as opposed to converting the bootloader). Fun!

[karter16]

I figured, but just double checking . Maybe throw a screenshot of that function up for code review completeness?

C code LGTM. I looked through the assembly and it also seems fine, but my assembly skills are rusty, so take that with a grain of salt.

sure thing - here we go :-). Note that CAN_send_frame() is the untouched original function that sends CAN frames to the bus.



Thanks! - I've validated it 3 different ways now

1: This morning I went through the assembly by hand, confirming what it was doing and validating it against its sister functions. As part of this I made sure to track the before/after states of all registers, the stack, etc.
2: I loaded the result in to Ghidra as you can see above and confirmed that both the disassembly and the C interpretation match what I expect.
3: I asked ChatGPT to interpret and summarize the assembly to check that it's interpretation of what was going on matched my own.

I'm at the point now where I can't really test it any further without loading it and giving it a go.

To that end I've taken the exact program binary currently on my car, made the above modifications to it, done a before after comparison to make sure I didn't change anything else by accident and loaded it also into Ghidra to validate the assembly and C.

Next up is to flash the program and try it out. As I mentioned I'm not setup for CAN logging, so will simply be validating that the DME, and car, runs without error. From that point on it'll be over to you and Bry5on to actually log the new message and confirm full functionality (if you're still game that is 😉)

Also if there's anything else you want to see in more detail (existing CAN message functions, etc.) let me know!

[heinzboehmer]

Ah it's the function that actually pushes the frame to the bus. I must have taken that screenshot before I labeled the function.


Sent from my iPhone using Tapatalk

I figured, but just double checking . Maybe throw a screenshot of that function up for code review completeness?

C code LGTM. I looked through the assembly and it also seems fine, but my assembly skills are rusty, so take that with a grain of salt.

[karter16]

This is awesome!

Question, what is FUN_0003aa20() doing?

Ah it's the function that actually pushes the frame to the bus. I must have taken that screenshot before I labeled the function.


Sent from my iPhone using Tapatalk

[heinzboehmer]

This is awesome!

Question, what is FUN_0003aa20() doing?

[karter16]

Counting the instruction clock cycles shows that this additional CAN message takes approximately 20us (micro-seconds) to run (that's for both the function that constructs the message and to actually push it onto the CAN bus).

I've spent some time going through my work and am probably about as happy as I can be with most of it, I'm still working out a couple of the config bytes in the CAN message table - They don't seem to be relevant for sent CAN messages but I need to be certain on those before I go any further.

After that will be to copy the changes into the flashable 0401 program binary and flash that to my DME as a guinea pig test. Amusingly I'm not setup for CAN logging so all I will be able to do is validate that the new program runs without error.

I'm a bit concerned that I wrote the machine code for the new functions and haven't found any issues whatsoever with that work since. Usually that just means that you haven't found the bug yet 😏