MSS6x Flasher - Now released!

[terra]

Thanks Terra for your response. It reflashed in WinKFP. I should note that I was using version 1.0.0.2. Should I update to 1.0.0.3 and try again flashing the RSA bypass fast?

Yeah I think the new version is worth a try. Seems like using the ftdi driver is a bit more stable for flashing.

[1984M3]

Does the dme respond at all in tool32 or inpa or WinKFP? If so try reflashing with WinKFP. I’d just use the update function - it’ll figure out the VIN and such from there on its own.

If it doesn’t send me the backup file you made and I’ll clone it onto my dme and overnight that to you.

I don’t think it is bricked if it got to the step you’re at.

Thanks Terra for your response. It reflashed in WinKFP. I should note that I was using version 1.0.0.2. Should I update to 1.0.0.3 and try again flashing the RSA bypass fast?

[1984M3]

Update to my post above: Reflashed the ECU with WinKFP. Put in my vin. Reflashed without a problem. Started the car up without any issues at all.

Used the program to identify the ECU afterwards as well.

[terra]

Does the dme respond at all in tool32 or inpa or WinKFP? If so try reflashing with WinKFP. I’d just use the update function - it’ll figure out the VIN and such from there on its own.

If it doesn’t send me the backup file you made and I’ll clone it onto my dme and overnight that to you.

I don’t think it is bricked if it got to the step you’re at.

[1984M3]

Had an error trying to flash the RSA Bypass fast. Using Bimmergeeks cable just bought. What should I do to recover or is my ecu permanently bricked? Should I try WinKFP to reprogram the ECU? Do I enter my full VIN in WinKFP or just the abbreviation?

[omhl]

Minor Update (Now Version 1.0.0.3)

Changes:

• The application will now default to using the D2XX Driver instead of the Virtual COM Port. This seems to be more stable for K-line mode communications, should not cause any regressions for other cars
  • In this mode, the settings you have in device manager (COM port, latency, etc) shouldn't matter.
  • If you wish to go back to the Virtual COM Mode, Edit the "MSS6x Flasher.exe.config" so that "Port" is set to the COM port you desire (default is now "FTDI0")
  • Note: This will probably not work properly if you have multiple FTDI devices connected at the same time. If you have multiple FTDI devices, you can try to select the specific device you want using the instructions under "FTDI D2XX Properties" here
• Eliminated the slow RSA bypass. Just seemed to create confusion.
• Made some changes so that if one of the stages during a flash process fails, the program doesn't try to perform the subsequent steps.

CaptainPunPants - Might be worth trying this version out with either of your cables.

It might be better to include a change log in main thread or within the zip folder. I think your notes about new releases might get lost in the thread eventually.

[terra]

terra is the bimmergeeks cable is the same as the one you helped me modify ?

Where I had to reprogram the Atmega chip ?

Honestly I don't really remember, but it sounds like it.

[cossie1]

terra is the bimmergeeks cable is the same as the one you helped me modify ?

Where I had to reprogram the Atmega chip ?

[terra]

Thanks terra, I'll review the FTDI properties and make sure I don't have any cable confusion. Further test will probably wait until next weekend (dealer appointment to get the silly OC3 weight mat issue warrantied before then).

To verify; a failure with the RSA bypass in normal (aka not-slow) mode will brick the DME beyond WinKFP's ability to recover, will it not?
That was my main motivation for slow mode, as I don't have a bench flash setup or non-factory tools (although this isn't my primary vehicle, I'm still trying to minimize headaches in case of problems).

2nd question: I didn't install a custom or manually-sourced FTDI chipset driver, just used the one Windows 10 pulls when connecting the cable. Does that pose a potential problem for these cables? I've never had an issue with coding/diagnostics, so never went beyond that.

It’s a fairly specific circumstance that will cause the failure in normal mode. Basically if bad bytes are written to the dme during that process and the authentication step is triggered, then yes, the dme will copy that bad data over the boot code and be hosed.

This only really happens when using a normal D-CAN cable on a D-CAN car since those cables have a bug that cause every 253rd byte to be written incorrectly when being used in D-CAN mode. But as far as my application knows, everything was written properly so it proceeds to trigger the authentication step. Normally I would try to mitigate this by reading back some data to make sure it’s valid, but Siemens in their infinite wisdom decided to make the dme unresponsive to read commands when programming is incomplete.

In a K-line car you’re not susceptible to that particular bug. And in the event of a flash failure like what you had, the authentication step isn’t actually triggered, so it shouldn’t try to copy incomplete boot code over.

Not sure about the driver. I think Windows installs the ftdi driver by default.

[Lucky]

I ordered the expert cable (not pro). I also will report whether it worked.

[CaptainPunPants]

Minor Update (Now Version 1.0.0.3)

Changes:

• The application will now default to using the D2XX Driver instead of the Virtual COM Port. This seems to be more stable for K-line mode communications, should not cause any regressions for other cars
  • In this mode, the settings you have in device manager (COM port, latency, etc) shouldn't matter.
  • If you wish to go back to the Virtual COM Mode, Edit the "MSS6x Flasher.exe.config" so that "Port" is set to the COM port you desire (default is now "FTDI0")
  • Note: This will probably not work properly if you have multiple FTDI devices connected at the same time. If you have multiple FTDI devices, you can try to select the specific device you want using the instructions under "FTDI D2XX Properties" here
• Eliminated the slow RSA bypass. Just seemed to create confusion.
• Made some changes so that if one of the stages during a flash process fails, the program doesn't try to perform the subsequent steps.

CaptainPunPants - Might be worth trying this version out with either of your cables.

Thanks terra, I'll review the FTDI properties and make sure I don't have any cable confusion. Further test will probably wait until next weekend (dealer appointment to get the silly OC3 weight mat issue warrantied before then).

To verify; a failure with the RSA bypass in normal (aka not-slow) mode will brick the DME beyond WinKFP's ability to recover, will it not?
That was my main motivation for slow mode, as I don't have a bench flash setup or non-factory tools (although this isn't my primary vehicle, I'm still trying to minimize headaches in case of problems).

2nd question: I didn't install a custom or manually-sourced FTDI chipset driver, just used the one Windows 10 pulls when connecting the cable. Does that pose a potential problem for these cables? I've never had an issue with coding/diagnostics, so never went beyond that.

[Martyn]

Yes you can

[Lucky]

one more question,

the binary modification tool only processes full file, no tune file.
So if i make changes in full file and load it back to MSS6x-flasher, can i nevertheless flash with Button "Flash Tune" ?

[Lucky]

ok, that seems to be all the same i can do with Binary Modification Tool ? Idle Speed, Rev Limit per Gear, all Checkboxes or throttle adjustments. This things all can be flashed with tune.

thanks !

i`ll try, but have do wait for cable

[terra]

does that mean, i have to load the full-file in Binary Modification Tool, then for example i set checkmark to "Vmax Limit Removal" - and then it`s enough to flash only the tune ?

Yep, that should be fine.