Hi, I have been using Ecuflash for a while now with my openport 2.0

I have had no problems to date (apart from usual novice issues a long time ago) but a couple of days ago I went to write a new ROM to the ECU and got an error.

Thankfully I always test write first so no harm done.

I rechecked everything, rebooted laptop, battery level is fine...

I tried to test write a prior ROM - same issue
I did a read, no problem and then did a test write back - same issue
I did an ECU compare - same issue.

I reinstalled the ECUFlash software - same issue

The log file sheds no light on it...

[13:13:10.171] J2534 API Version: 04.04
[13:13:10.171] J2534 DLL Version: 1.00.3721 Jan 9 2013 17:24:59
[13:13:10.171] Device Firmware Version: 1.12.3688
[13:13:10.171] Device Serial Number: TA7H**sW
[13:13:13.140] sending init sequence 1 (0003)
[13:13:14.140] got 0x05 response
[13:13:14.140] sending init sequence 2
[13:13:14.140] got 0x1B response
[13:13:14.140] sending init sequence 3
[13:13:14.484] entering bootloader
[13:13:14.484] sending kernel size (0)
[13:13:14.484] sending kernel load address (0xFFFF6000)
[13:13:14.484] uploading kernel
[13:13:14.484] verifying kernel checksum response
[13:13:14.484] kernel valid
[13:13:14.500] sending init sequence 2
[13:13:16.515] interface close

I may try my other laptop and see if that works.

The only thing I changed was I updated the definition file to a different one. I may revert to the old one and see if that works but I can't understand why that would make a difference.

Has anyone else hd this isue?

 

Tried anoher laptop, still same issue.

Buggered Openport 2.0?

Any suggestions greatly appreciated.

 

Anyone?

 

Try your original xml file.

 

Thanks, I tried that, same issue.

 

Is your battery level low?

 

Nope, battery level is good - almost new battery.

I also tried giving it a run and then trying a test write straight afterwards to eliminate that.

I reckon it is the openport 2.0 - This problem manifested itself without warning...

The openport 2.0 will read and it will log data to the micro SD card. I think I may raise a ticket with Tactrix.

The other alternative is that it is the Evodroid that has caused this

Seriously though, has anyone considered whether constant connection to the OBD port may cause issues?

 

Seems like it was the definition file, went to an older file and it worked.

Tactrix were great in diagnosing the issue..

 

So what did you do differently this time?

 

There is a known issue with EcuFlash that I forgot about :-)

I renamed the xml file in use and renamed the older one to the ECU id. You would think that EcuFlash would use the one with the correct name right?

Nope, it still uses the same one even though it has been renamed. I only picked this up after getting Tactrix to send me a script to change the registry settings to allow for more detailed debugging.

Tactrix suggested that the definition was causing the issue so I double checked the log - and there it was, the log showed that EcuFlash was still using the same xml file (the re-named one)

 

If I need to change an xml I just cut the original one out of my rommetadata folder and then paste the new one in there. That always works.

 

Just renaming it won't do, you have to edit it to ignore the ecu ID you're trying to work with.

Wreckleford's suggestion is probably the best thing to do though.

 

Yes, this should serve as a timely reminder of this 'feature' I knew about this and still fell into the trap.