NefMoto

Hi,
I see here a lot of ME ECU's threads about how to make simulation via Roadrunner or other moates tools work.
As you may know EDC15P is very familar ECU, have similar psop44 flash driver and processors are really related to each other.

In conclusion I may share the info what I've found here about ME (which nearly impossible to adapt to EDC15P ECU's).

We need to do 2 things: patch flash file (for start ups) and eeprom (for running engine and successful live tuning).


The first patch is to check checksum when ECU is powering up (IGNITION ON). The EEPROM mod is to disable checksums while ECU is running, which is the really important part.

In my personal experience using original WinOLS version with emulation plugin + Roadrunner 2.0 on 1.9 TDI PD EDC15P you can make numerous of changes, but after (20-30 changes) ecu gets ended with bricking eeprom, and you need to reflash it. (WITHOUT patches or modifications made of prj guide).

If we go to dump and search familar areas, we can find:
Only one result on every EDC15P dump


As guide says we should change it to (last 4 bytes found on: E6 F4 FF DF, btw it can be found too without problems).


What's next? E2p, but here where we face the problem, EDC15P E2p has complete diff form and structure. There is nothing similar and as I understand E2p is the main thing you must to do, to solve this puzzle and make it run.

Maybe someone have ideas to make it happen?
And what about processor code? Do we need to change that too, to make flash solution work or flash is enough?

I don't think there is a true way around this to be honest, having used the RR a lot in the past the best way I found to use it and I am sure it will be the same for the EDC15p, is to forget about trying to disable the checksum stuff and just use the RR as if it where a normal flash and correct the check sums as you go..

The easiest and best way of doing this is to use tunerpro, with the checksum correction and then use emutility to monitor and up load the corrected file to the RR.. Make a change to the map, save it and correct checksum and then Emutility will see the changes and upload them to the RR including the Chksums.. That way you don't have to worry about wrong checksums or bricking the ecu..

Only issue is that you don't save the individual changes as it's a running change but if you save the modified file and then save as, for the new version then you keep the versions, but does mean double saving ..

So this is something I've been wondering... Maybe I'm confused by what littco has said because I can't see why you'd bother disabling checksums if this is the case...

If you were to use Emutility and kept over-writing the file that Emutility is monitoring with a file with corrected checksums... Will this cause a stall? I don't particularly know the exact process for checksums, so forgive me. Is the runtime checksum value loaded into RAM at startup and held there (I'd be surprised if that was the case..?) or is it simply checked periodically during runtime with the value stored in flash.

If the latter is the case - surely as long as the file has corrected checksums, this isn't a problem...?

It wouldn't be a problem to create some sort of script at the press of a button to:

1. Export the file from your favourite tuning software
2. Checksum the file
3. Byteswap the file (if you don't have a byteswap board...)
4. Overwrite the file being monitored by Emutility and changes get written to the flash
5. ???
6. Profit.

Frankly even if it were the case that changes live on the ECU aren't possible, it's more than worth it to be able to quickly stop engine, make changes, checksum, hit button, restart. Still a lot faster than flashing another file via OBD.

Live changes are not possible, the engine will stall and restart because for a moment the checksum routine will fail.

That's that idea out the window.

I'm amazed the runtime checksum is calculated that frequently/quickly. Oh well, back to IDA I go... Wish I wasn't so shit at it.

Yes, littco was correct sayin you just need to live on with what you have.


At the moment I have used OLS300 often and started to see which maps are very sensitive to modifications while running live session with ECU.
Most frequently ECU is checking ignition and fuel related maps, others like n75 calibration, boost request, limitation, rpm limiters, launch control and even BIP's are checked not so frequently and you can work for while without bricking it, most annoyed maps in stage 3 tuning are boost maps and their control related maps, quite time saver at this point. E.g. ignition and durration changes can be made +/- 5-6 times, before it bricks.

P.S. After new OLS300 release it was starting to doing job few times better than before in 2013-14, checksums now are pushed more faster + mention to have USB wire not too long or buy optic USB cable adapter, this is good for ME ECU's because of ignition coils noise.