CSL '0401' Program Binary Disassembly Notes

[HARBER07]

It was more of my curiosity than anything at this stage. I was just wondering if any changes could be made to the safety/operating state when sensors fail…. Eg. MAP, EGT or IAT etc.

i shall have a read of that document when I get a chance though as I’d missed that one completely.

[karter16]

Have you looked into how the ‘emergency program’ / limp mode operation works?. I’m wondering what changes it enables when it kicks in and any adjustability

Yep I have - and this funktionsrahmen document is fairly accurate if you're looking to get an understanding of how it works: https://github.com/karter16/CSL_0401...%20Concept.pdf

Note that this doc doesn't talk to CSL-specific changes (specifically how rf (filling) errors are detected and escalated to the EGAS emergency program).

in terms of adjustability what would you be wanting to change?

[HARBER07]

Have you looked into how the ‘emergency program’ / limp mode operation works?. I’m wondering what changes it enables when it kicks in and any adjustability

[terra]

Something else that I've been looking at is a binary that terra shared with me that came from a brand new CSL DME. This DME in particular was shipped without the tune file programmed to it. In its place is what I believe is a manufacturer test software to test the unit on the (Siemens) assembly line.

the MSS54 bootloader has provision to jump to this location (there's actually a DS2 call to perform the jump) and treat the region as code.

The software appears to be a basic main loop that handles communications between the master and slave processors, as well as a very DS2-like communications protocol (literally the only differences seem to be the message ID and length bytes are swapped, the checksum calculation is different and the actual device/command IDs are different) on the same pins as DS2.

The functions that can be called all test different aspects of the DME and CPU hardware and validate their functionality.

There are also several functions for reading/writing/wiping the flash memory. Crucially the function that wipes flash sectors includes the ability to wipe and write to the bootsector. You can probably see where I'm going with this...

1: Load the code into the tune sector in place of the tune
2: DS2 call to jump to the program
3: Wipe bootsector
4: Write new bootsector
5: Reboot DME
6: Write new Program for new bootloader
7: Write new Tune for new bootloader
8: Fin.


It would be trivial to extend the MSS54 DS2 Tool to use the modified communication protocol when needed, but this introduces a different risk, which is that when the DME is in the car there are other modules listening on DS2 and the possibility can't be discounted of a packet being seen as valid by one of those other modules and causing unintended havoc. Therefore I think the way to go is a small wrapper that translates standard DS2 calls into the format required by the manufacturer test code. That way comms to the DME stays compliant with the DS2 protocol but also means very minimal change to the test software.

This will be fun to see if I can make it work, but will need to wait until I get hold of a second DME as don't want to be regularly taking my main DME apart to BDM recover it which will inevitably be required for this project.

This would enable the following functionalities:

- Change bootloader over OBDII
- Clear EWS and perform an initial sync
- It would also significantly lower the barrier to use should we want to make any bootloader-level changes as part of 0401 Community Patch in the future.

Great work there! Sometimes my data hoarding is useful ha

[karter16]

Well enormous thanks to bmwfnatic and ZiMMie - DME is on its way to me. This means I'll be able to put together a bench setup that will allow for lots more experimentation (and a greater tolerance for failure!). I'm very grateful to you both, this community is amazing!!

[ZiMMie]

Just pay me for shipping and I'll give you a DME, as my contribution to this project :P

I'll pay for shipping for you to ship to to him. Sent you pm.

[bmwfnatic]

This will be fun to see if I can make it work, but will need to wait until I get hold of a second DME as don't want to be regularly taking my main DME apart to BDM recover it which will inevitably be required for this project.

Just pay me for shipping and I'll give you a DME, as my contribution to this project :P

[karter16]

Something else that I've been looking at is a binary that terra shared with me that came from a brand new CSL DME. This DME in particular was shipped without the tune file programmed to it. In its place is what I believe is a manufacturer test software to test the unit on the (Siemens) assembly line.

the MSS54 bootloader has provision to jump to this location (there's actually a DS2 call to perform the jump) and treat the region as code.

The software appears to be a basic main loop that handles communications between the master and slave processors, as well as a very DS2-like communications protocol (literally the only differences seem to be the message ID and length bytes are swapped, the checksum calculation is different and the actual device/command IDs are different) on the same pins as DS2.

The functions that can be called all test different aspects of the DME and CPU hardware and validate their functionality.

There are also several functions for reading/writing/wiping the flash memory. Crucially the function that wipes flash sectors includes the ability to wipe and write to the bootsector. You can probably see where I'm going with this...

1: Load the code into the tune sector in place of the tune
2: DS2 call to jump to the program
3: Wipe bootsector
4: Write new bootsector
5: Reboot DME
6: Write new Program for new bootloader
7: Write new Tune for new bootloader
8: Fin.


It would be trivial to extend the MSS54 DS2 Tool to use the modified communication protocol when needed, but this introduces a different risk, which is that when the DME is in the car there are other modules listening on DS2 and the possibility can't be discounted of a packet being seen as valid by one of those other modules and causing unintended havoc. Therefore I think the way to go is a small wrapper that translates standard DS2 calls into the format required by the manufacturer test code. That way comms to the DME stays compliant with the DS2 protocol but also means very minimal change to the test software.

This will be fun to see if I can make it work, but will need to wait until I get hold of a second DME as don't want to be regularly taking my main DME apart to BDM recover it which will inevitably be required for this project.

This would enable the following functionalities:

- Change bootloader over OBDII
- Clear EWS and perform an initial sync
- It would also significantly lower the barrier to use should we want to make any bootloader-level changes as part of 0401 Community Patch in the future.

[karter16]

Time for an update!

After a lot of time, a few attempts, and lots of reference to the EDK/WDK module which is actually similar in some regards and helps with naming conventions etc. I've mapped out the functions for the CSL snorkel flap. Below is my equivalent of a "funktionsrahmen" for this module which, although it no doubt exists for real, I don't have it, so this will have to do. Function names, variable names and parameter names are all mine (with the exception that we know from the DS0 file disassembly that the module is called GKS), but are named logically in line with how equivalent variables and parameters are named in other modules, etc.

[terra]

Cool. I guess 'Address access time = (2.5 + WS) t_cyc – t_CHAV – t_DICL' is probably the relevant formula? Though t_CHAV has a rather large range in the datasheet so I'm not sure what to enter as a calculation. Seems like BMW is selecting flash memory that should allow for 0 wait states in most scenarios.

If I assume the target access time would be proportional to the clock speed difference, ~76ns should be acceptable (assuming 20.97MHz for MSS52/4 and 24.76 MHz for MSS54HP which I believe is correct) -- so either way I think you're right in the 70ns likely being acceptable (there are also some ancient 29f400ab's occasionally available that came in 75ns, those may work too)

[karter16]

I think this is the right diagram (from page 283 onwards here: https://github.com/karter16/CSL_0401.../MC68376.pdf):



The whole read cycle is approximately 4 clock cycles, but the data needs to be stable on the bus by the time DSACK is low for sampling. I didn't go through the table and work it out but it looks to me to be somewhere in the region of 1.25 to 1.75 clock cycles between the address being stable and data needing to be read (So as you say, less than 2 clock cycles).

I would imagine from this that 70ns is probably just fast enough to work, but I don't know whether it's too close to the edge (pun intended) or not. I'd think 90ns would likely be less successful given that's definitely more than 2 clock cycles.

[terra]

Karter - since you seem to have a decent handle on the DME's timing, was wondering if you had any thoughts on how critical the flash memory's rated access time is. Every factory MSS54HP I've seen had the 55ns parts. But I've also seen people use the 70ns parts without apparent issue. MSS52/4 seem to have come with 70ns and 90ns from what I've seen.

If I did the math right, a single cycle on an MSS54HP (25MHz) would take 40ns and on an MSS52/4 (20MHz) would be 50ns -- so seems like they're targetting an access time that's less than what two cycles would take? If upto 80ms is acceptable, makes sourcing flash memory for HP conversions a little easier

(though old MSS52s seem to have a slightly older revision of the CPU, which does make me wonder if those would be suitable for the MSS54HP code at all)

[terra]

Was working through some unknown variables in the DPR that needed figuring out and came across this:



This is where the CVNs are generated for CARB. They're built off the CRCs of the various sections same as is done elsewhere, but here they're XOR'd with various values - I'm gunna go ahead and guess that that was to stop it being used as a way to generate checksums (unless anyone has any other ideas) the CARB specification makes no mention of anything that would explain it.

I guess it makes it harder to generate an arbitrary checksum if you don't know the algorithm, but if one makes the connection that generating a checksum to match the original results in the CVN also matching the original, then it's kinda moot. They probably just thought they were being cute with the MS_S stuff.

CARB does leave it entirely to the manufacturer on how to calculate it. On various non-M DMEs from the E6x/9x generation (MS45, MSx70/8x), the CVN is simply the same as the stored checksum (CRC32 in those cases). I'm not sure about MSS6x, I never looked into that.

[karter16]

4D 53 5F 53 35 34 35 32 in ASCII reads MS_S5452

Ha nice! I'd missed that


Sent from my iPhone using Tapatalk

[bmwfnatic]

4D 53 5F 53 35 34 35 32 in ASCII reads MS_S5452