MSS54 DS2 Tool: FREE TOOL for programming DME - Tune, full binary, flash counter, etc

[karter16]

Awesome work! Will test it soon.

I don't know if you have implemented security checks like flashing CSL bootloader in non CSL boot loader ECU?
I would expect a check between file and actual data in ECU. This would reduce the risk of a brick.

Don't know if you want to implement more diagnostic information? Activate actuators, DMTL checks and VANOS check? I could support you on the VANOS check.

The MSS5x ECU also holds cylinder individual CO trims. I don't know were these are stored yet. Since the ECUs I have read have different values, I suspect these are adjusted in the factory with special manifold or other procedure.
In any case its useless once you don't have extraction points on your exhaust manifolds (Like S38, S15 and S50).
I do have my own INPA IPO file to adjust these on MSS50.

Awesome - yep the software will prevent flashing a program that doesn't match the bootloader, and prevent flashing tune that doesn't match the program.

Yep I'm thinking that diagnostic actions are something that could follow. Probably the common ones like vanos, CSL flap actuation, etc. at least. funny, I was actually looking at the DS2 calls for the VANOS check yesterday!

Re the individual trims are you talking about ti_ll_z1 thru ti_ll_z8? (injection timing adjustments per cylinder to balance out uneven running) If so they're stored in the EEPROM adaptions block and are actually dynamically adapted by the DME. If you mean something else let me know and I can have a look :-)

[Tomba]

Awesome work! Will test it soon.

I don't know if you have implemented security checks like flashing CSL bootloader in non CSL boot loader ECU?
I would expect a check between file and actual data in ECU. This would reduce the risk of a brick.

Don't know if you want to implement more diagnostic information? Activate actuators, DMTL checks and VANOS check? I could support you on the VANOS check.

The MSS5x ECU also holds cylinder individual CO trims. I don't know were these are stored yet. Since the ECUs I have read have different values, I suspect these are adjusted in the factory with special manifold or other procedure.
In any case its useless once you don't have extraction points on your exhaust manifolds (Like S38, S15 and S50).
I do have my own INPA IPO file to adjust these on MSS50.

[terra]

The latter is how I do it in mss6x flasher (minus restoring adaptions etc), but that's also partly because on those DMEs writing a program wipes the tune so it's pretty much necessary. I do like the idea of having a 'one click' solution to accomplishing what is essentially a complete restore from a different backup (minus ISN I guess). Could be useful for those scenarios where one needs to swap back to a stock tune not want to go through the hassle of setting the drive cycles again etc.

Another thought I had was adding a RAM dumping functionality, though again probably mostly useful for us tinkerers out there.

[karter16]

I assume it's a deliberate design choice to not allow flashing a tune from a full bin?

Yeah interesting. It was in that I felt it was unnecessary complexity for the user to understand. But if we think it's a common use case then I t would be easy for me to add. I think probably allow the user to select a full bin when writing tune and then just pop a confirmation to the user to confirm that's what they want to do?

Other option would be to entirely flip the paradigm around and have a single “write” function and based on the source file type the user selects then given them the option of what segment/s they want to write? Maybe that's simpler? (this would also make it easy then if say a user had one DME and swapped back and forth between M3 and CSL progs. They could then choose to restore their Adaptions (EEPROM) block, etc. as well if they wanted.)


Sent from my iPhone using Tapatalk

[terra]

I assume it's a deliberate design choice to not allow flashing a tune from a full bin?

[karter16]

Live Values/Logging Proof of Concept (This is not available in the current version)

Modelled on, what I presume is, the same approach that TestO uses which is calling the DS2 I/O sample messages (means you get a whole set of values in a single DS2 call). Essentially select the "sets of values" you want to see on the left and side, and then see the values in the table on the right hand side. From a live-read perspective there's no performance benefit in selecting single values to display. I will definitely be building out the ability to select what specific values to log to CSV though.

The ultimate data rate is limited by the DS2 protocol at 9600 baud. If you select a single set of values like the screenshot below you can see the data frequency is about 10Hz, as you select more sets to include the frequency drops accordingly due more more frames transiting the bus.

[0-60motorsports]

Gentlemen any links for where to buy a good cable to use with this?

[karter16]

Seems to work!

Awesome thanks for the confirmation!!!

[terra]

Seems to work!

[karter16]

KL30 on, KL15 off (I don't have KL15 wired on my bench setup, and honestly I'm not 100% sure if my cable even reports it). It seems just going to any screen and then back to the connect screen causes the behavior. But it was mostly writing that I messed with

I'll recreate and grab a log tonight

Found and fixed! (I think)

v1.0.2 is now published: https://github.com/karter16/MSS54-DS...ublic/releases

Please give it a go when you get a chance and let me know if the issue is now resolved :-)

[karter16]

Awesome thanks guys - I'm pretty sure it's going to be a scenario that isn't properly accounted for. Let me investigate and see what I can come up with. My cable does report KL15 which makes it a bit hard to test that the cases where it isn't are handled properly - I thought I had it nailed but it seems not.

[ac427]

hmmm interesting. Couple of questions:

- Do the KL30 and KL15 lines show as on? or do you see them marked as off? (I wonder if this is it and I have an unaccounted-for scenario in the reconnection logic)
- What sorts of things have you done prior to going back to the connect screen? read/write? or just read?

If you're able to grab the log file from that session and send it to me that would be super-helpful in figuring out what's happened :-)

KL30 on, KL15 off (I don't have KL15 wired on my bench setup, and honestly I'm not 100% sure if my cable even reports it). It seems just going to any screen and then back to the connect screen causes the behavior. But it was mostly writing that I messed with

I'll recreate and grab a log tonight

I think i had this too. When i reset the Flash counter. Once the write was over i am sure had to quit the app to reconnect. I'll try to recreate it.

[terra]

hmmm interesting. Couple of questions:

- Do the KL30 and KL15 lines show as on? or do you see them marked as off? (I wonder if this is it and I have an unaccounted-for scenario in the reconnection logic)
- What sorts of things have you done prior to going back to the connect screen? read/write? or just read?

If you're able to grab the log file from that session and send it to me that would be super-helpful in figuring out what's happened :-)

KL30 on, KL15 off (I don't have KL15 wired on my bench setup, and honestly I'm not 100% sure if my cable even reports it). It seems just going to any screen and then back to the connect screen causes the behavior. But it was mostly writing that I messed with

I'll recreate and grab a log tonight

[karter16]

Overall works great! Potential bug, and I'm not sure if this is a quirk of doing things on the bench with a frankensteined DME (early MSS52 with 0F70K CPUs and 29F400AB flash memory flashed with a CSL binary), but if I go back to the connect screen after doing stuff, the program seems to disconnect from the DME and doesn't successfully reconnect (in either COM mode or D2XX) without closing and restarting.

hmmm interesting. Couple of questions:

- Do the KL30 and KL15 lines show as on? or do you see them marked as off? (I wonder if this is it and I have an unaccounted-for scenario in the reconnection logic)
- What sorts of things have you done prior to going back to the connect screen? read/write? or just read?

If you're able to grab the log file from that session and send it to me that would be super-helpful in figuring out what's happened :-)

[terra]

Overall works great! Potential bug, and I'm not sure if this is a quirk of doing things on the bench with a frankensteined DME (early MSS52 with 0F70K CPUs and 29F400AB flash memory flashed with a CSL binary), but if I go back to the connect screen after doing stuff, the program seems to disconnect from the DME and doesn't successfully reconnect (in either COM mode or D2XX) without closing and restarting.