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