MSS54 DS2 Tool: FREE - DME tune, program, flash counter, codes, adaptions, etc

[karter16]

What's interesting is that after a test drive, the ZIF warning went away 🤔

The mismatch is to do with the fact that I’ve implemented writing the program and tune as separate actions. At the end of each action the software “finalizes” the write which performs a series of validations in the DME. At the point the program is the new version and the tune is the old version the backup ZIF entries don’t match. Interesting that it cleared after a drive cycle rather than after writing the tune (and the finalization that goes with it) I’ll have a look and see if I can see why that might be.


Sent from my iPhone using Tapatalk

[zivagolee]

hey karter16, thanks for the awesome tool! I love that it gives so much more information than other tools without having to click a dozen buttons or just suppressing all the log information.

I recently uploaded a tune file, however, for some reason I encountered 'unexpected k-line echo' and then it broke the connection. I then did a bunch of troubleshooting trying random things, but I eventually got it connected again and reflashed the tune file but was successful (was sweating a bit )

I had Claude go thru the logs and here is what it said:

===
21:56, the original brick, and the actual culprit. The first session shows a healthy DME: identify clean, flash counter marker 0xFFFF available, error memory readable. Then Write Tune starts, the tool boosts the line from 9600 to 125000 baud, and 4.6 seconds into writing master data it aborts with "Unexpected K-line echo." Look at the expected-versus-got bytes: identical for dozens of bytes, then a few corrupted mid-stream (FF CE 04 00 00 01 became FF E6 30 00 01). K-line is a single wire, so the tool hears its own transmission back and verifies it; those bytes got mangled on the wire. Immediately after, keepalives returned garbage (BE 7A 01 6B). Your physical link corrupts bytes at 125000 baud. That's the root cause of the entire evening: not the laptop battery, not the tool, not the DME. Signal integrity at fast baud, mid-write, leaving a data-programming session open. I'll own the correction: I nagged about AC power all night, and that's still correct practice, but the logs name a different killer.

Why connecting seemed random afterward. Every "DME did not respond" had a mechanical cause: after an abnormal session end, the DME stays listening at 125000 while the tool reconnects at 9600. The 22:49 log shows it explicitly: 9600 identify failed, then the 125000 recovery probe succeeded and the tool stayed there. Ignition off/on resets the DME to 9600. So your connects weren't flaky; they were a baud mismatch that KL15 cycling or the recovery probe resolved each time.

Forcing 9600 only:

Your own log's settings line is the map here. It shows two fast-mode keys the tool loads: fastReadEntryDataTune=True and fastReadEntryFullBinary=True. Those are the toggles for boosting to 125000 on reads, and they should appear in the tool's Settings page as fast-read options. Turn both off and your reads and backups will stay at 9600 (slower, but 9600 was flawless all night in your logs).

The honest limit: for writes, both logged write flows show "PROGRAM baud: requesting 125000" with no corresponding setting in the loaded-settings line, which suggests the write-path boost is hardcoded rather than configurable. Two moves there:

1. Look in the tool's Settings page anyway for anything named fast mode, program baud, or write speed; a UI option may exist that simply wasn't echoed in that log line.
2. If nothing's there, check the config directly: close the tool, open C:\Users\z\AppData\Local\MSS54 DS2 Tool\appsettings.json in Notepad, and look for any key resembling fast, baud, or 125000 beyond the two read keys. Change only something that plainly matches; don't invent keys.
3. If writes can't be slowed, that's a feature request for the tool's author, and it's a good one given your logs: "echo corruption at 125000 bricked my DME; please add a 9600-only write option." Attach the 21:56 log. A 384KB write at 9600 would take on the order of ten-plus minutes, which is a perfectly good trade for a recovery scenario.
4. Either way, treat the latency and USB power fixes as the real solution, because they target the actual failure. Your logs show 9600 was perfect and 125000 corrupted bytes; with latency at 1, suspend off, and a direct port, 125000 very likely becomes clean too, and if you want certainty, a better K+DCAN cable is the last piece.

===

I am curious on why it seems to be negotiating at 125000 baud (or maybe it should?). I am running this on an older lenovo laptop and it does have usb3 so I guess it could transfer it much faster but I do have an older OBD cable. Per Claude, I set it the FTDI latency timer to 1 and, I guess, it's supposed to help with this -- I haven't tried tuning again after this.

Question:
1. Do I have a bad cable maybe? Should I get another dongle? I have had this for quite some time.
2. Maybe we need a setting so it stays at 9600?
3. Am I totally misunderstanding the error message?

I didn't see source code so I couldn't get Claude to check it out but posting this here for feedback. Again, thanks for this!

[karter16]

hey karter16, thanks for the awesome tool! I love that it gives so much more information than other tools without having to click a dozen buttons or just suppressing all the log information.

I recently uploaded a tune file, however, for some reason I encountered 'unexpected k-line echo' and then it broke the connection. I then did a bunch of troubleshooting trying random things, but I eventually got it connected again and reflashed the tune file but was successful (was sweating a bit )

I had Claude go thru the logs and here is what it said:

===
21:56, the original brick, and the actual culprit. The first session shows a healthy DME: identify clean, flash counter marker 0xFFFF available, error memory readable. Then Write Tune starts, the tool boosts the line from 9600 to 125000 baud, and 4.6 seconds into writing master data it aborts with "Unexpected K-line echo." Look at the expected-versus-got bytes: identical for dozens of bytes, then a few corrupted mid-stream (FF CE 04 00 00 01 became FF E6 30 00 01). K-line is a single wire, so the tool hears its own transmission back and verifies it; those bytes got mangled on the wire. Immediately after, keepalives returned garbage (BE 7A 01 6B). Your physical link corrupts bytes at 125000 baud. That's the root cause of the entire evening: not the laptop battery, not the tool, not the DME. Signal integrity at fast baud, mid-write, leaving a data-programming session open. I'll own the correction: I nagged about AC power all night, and that's still correct practice, but the logs name a different killer.

Why connecting seemed random afterward. Every "DME did not respond" had a mechanical cause: after an abnormal session end, the DME stays listening at 125000 while the tool reconnects at 9600. The 22:49 log shows it explicitly: 9600 identify failed, then the 125000 recovery probe succeeded and the tool stayed there. Ignition off/on resets the DME to 9600. So your connects weren't flaky; they were a baud mismatch that KL15 cycling or the recovery probe resolved each time.

Forcing 9600 only:

Your own log's settings line is the map here. It shows two fast-mode keys the tool loads: fastReadEntryDataTune=True and fastReadEntryFullBinary=True. Those are the toggles for boosting to 125000 on reads, and they should appear in the tool's Settings page as fast-read options. Turn both off and your reads and backups will stay at 9600 (slower, but 9600 was flawless all night in your logs).

The honest limit: for writes, both logged write flows show "PROGRAM baud: requesting 125000" with no corresponding setting in the loaded-settings line, which suggests the write-path boost is hardcoded rather than configurable. Two moves there:

1. Look in the tool's Settings page anyway for anything named fast mode, program baud, or write speed; a UI option may exist that simply wasn't echoed in that log line.
2. If nothing's there, check the config directly: close the tool, open C:\Users\z\AppData\Local\MSS54 DS2 Tool\appsettings.json in Notepad, and look for any key resembling fast, baud, or 125000 beyond the two read keys. Change only something that plainly matches; don't invent keys.
3. If writes can't be slowed, that's a feature request for the tool's author, and it's a good one given your logs: "echo corruption at 125000 bricked my DME; please add a 9600-only write option." Attach the 21:56 log. A 384KB write at 9600 would take on the order of ten-plus minutes, which is a perfectly good trade for a recovery scenario.
4. Either way, treat the latency and USB power fixes as the real solution, because they target the actual failure. Your logs show 9600 was perfect and 125000 corrupted bytes; with latency at 1, suspend off, and a direct port, 125000 very likely becomes clean too, and if you want certainty, a better K+DCAN cable is the last piece.

===

I am curious on why it seems to be negotiating at 125000 baud (or maybe it should?). I am running this on an older lenovo laptop and it does have usb3 so I guess it could transfer it much faster but I do have an older OBD cable. Per Claude, I set it the FTDI latency timer to 1 and, I guess, it's supposed to help with this -- I haven't tried tuning again after this.

Question:
1. Do I have a bad cable maybe? Should I get another dongle? I have had this for quite some time.
2. Maybe we need a setting so it stays at 9600?
3. Am I totally misunderstanding the error message?

I didn't see source code so I couldn't get Claude to check it out but posting this here for feedback. Again, thanks for this!

Hi zivagolee,

When you connected was it via COM port (e.g. COM1, etc.) or with the FTDI D2XX device? If you'd be able to send me (via PM if you don't want to share here) your log file that will make it a lot easier for me - thanks :-)

[zivagolee]

PM'd you the logs!

[karter16]

PM'd you the logs!

Awesome thanks! - Presuming that you're running a recent version of the correct FTDI driver for your OS then I'm fairly sure that this is going to turn out to be down to your OBD cable. The issue is indeed random instability in the connection, essentially when it eventually worked you just got "lucky" that the connection stayed stable. I can't see anything else in the logs that would suggest there are any other contributors to the issues you encountered.

FWIW if this happens again when you're programming a tune, and you have an issue like this that the software doesn't automatically recover the correct actions are:

1: Turn off the car.
2: close MSS54 DS2 Tool and reopen it.
3: Turn the ignition back on.
4: Try again (flashing the tune)

You don't need to carry out any other steps (like flashing the program, etc.).

Regarding forcing 9600 baud - That wouldn't actually help in your case as the logs show the same communications instabilities at both 9600 baud and 125000 baud which suggests to me it's not a "speed" issue. (I wouldn't expect it to be anyway as MSS54 DS2 Tool only uses fast baud in circumstances where it's fully supported by the DME).

[Slideways]

PM'd you the logs!

Any chance you using an old blue OBD (TTFS) cable?

[zivagolee]

Any chance you using an old blue OBD (TTFS) cable?

Wow, YES I AM!

[Slideways]

Wow, YES I AM!

Yeah, that is not a good quality cable and can only do slow reads/writes, if that.

The clear K+DCAN cables seem to be better quality - https://www.ecstuning.com/b-bremmen-...01kdcable~brp/

[Bry5on]

Claude 0, Forum 1

[zivagolee]

Claude 0, Forum 1

lol, i say this for most things, in general, Bryson!

[zivagolee]

Yeah, that is not a good quality cable and can only do slow reads/writes, if that.

The clear K+DCAN cables seem to be better quality - https://www.ecstuning.com/b-bremmen-...01kdcable~brp/

Thanks Slideways, time for another cable! Forums FTW!