openecu.org

I tried to work with EVO-ECUs using EcuFlash 1.22 and have discovered some problem (???) with connect stabilty.
ECU replies excellent on 9600-init strings and after switching on high baudrate (62500 bps) it doesn't continue work in bootstrap-mode.

Typically log is as follows:
[07:47:32.487] Version 1.22.373
[07:47:32.487] 9 memory models read.
[07:47:32.627] 62 ROM metadata models read.
[07:47:32.627] flashing tool "wrx02" loaded.
[07:47:32.627] flashing tool "wrx04" loaded.
[07:47:32.627] flashing tool "sti04" loaded.
[07:47:32.627] flashing tool "sti05" loaded.
[07:47:32.627] flashing tool "evo" loaded.
[07:47:32.627] flashing tool "shbootmode" loaded.
[07:47:32.627] flashing tool "shaudmode" loaded.
[07:47:32.627] error loading FTD2XX.DLL
[07:47:43.883] sending init sequence 1 (0001)
[07:47:44.925] got 0x05 response
[07:47:44.925] sending init sequence 2
[07:47:44.955] got 0x1B response
[07:47:44.955] sending init sequence 3
[07:47:45.375] entering bootloader
[07:47:45.385] sending kernel size (3428)
[07:47:47.418] error sending kernel size
.....

But this situation occurs not everytime. Sometimes (absolute unpredictable) it works normal - enter bootstrap, load kernel, read and write...
I tested this on the car and on the table with several ECUs (evo7/8 ) I have by hand - all of them show the same behaviour...
I don't think that the slow interface hardware is a reason - the same i/face works fine and stable with Audi-VW ECUs on 125kbaud.

Have anyboby and aspecially cboles any comments?

[07:47:32.627] error loading FTD2XX.DLL

i think you will find the above is your problem. the evo needs those newer FTDI drivers for comms.

download and install those drivers (be aware that nothing else besides ecuFlash is compatible with those drivers at present) and your problem will most likely be resolved. colby can confirm this.

calvin.

0. This is beta software, and so I did not bother to turn off the EVO support in this version
1. I have not officially released a version which supports the EVO yet
2. You do not have hardware which supports reading the EVO using EcuFlash software
3. Did I mention the EVO is *not supported* in this version?

evoman wrote:I tried to work with EVO-ECUs using EcuFlash 1.22 and have discovered some problem (???) with connect stabilty.
ECU replies excellent on 9600-init strings and after switching on high baudrate (62500 bps) it doesn't continue work in bootstrap-mode.

Typically log is as follows:
[07:47:32.487] Version 1.22.373
[07:47:32.487] 9 memory models read.
[07:47:32.627] 62 ROM metadata models read.
[07:47:32.627] flashing tool "wrx02" loaded.
[07:47:32.627] flashing tool "wrx04" loaded.
[07:47:32.627] flashing tool "sti04" loaded.
[07:47:32.627] flashing tool "sti05" loaded.
[07:47:32.627] flashing tool "evo" loaded.
[07:47:32.627] flashing tool "shbootmode" loaded.
[07:47:32.627] flashing tool "shaudmode" loaded.
[07:47:32.627] error loading FTD2XX.DLL
[07:47:43.883] sending init sequence 1 (0001)
[07:47:44.925] got 0x05 response
[07:47:44.925] sending init sequence 2
[07:47:44.955] got 0x1B response
[07:47:44.955] sending init sequence 3
[07:47:45.375] entering bootloader
[07:47:45.385] sending kernel size (3428)
[07:47:47.418] error sending kernel size
.....

But this situation occurs not everytime. Sometimes (absolute unpredictable) it works normal - enter bootstrap, load kernel, read and write...
I tested this on the car and on the table with several ECUs (evo7/8 ) I have by hand - all of them show the same behaviour...
I don't think that the slow interface hardware is a reason - the same i/face works fine and stable with Audi-VW ECUs on 125kbaud.

Have anyboby and aspecially cboles any comments?

0. This is beta software, and so I did not bother to turn off the EVO support in this version
1. I have not officially released a version which supports the EVO yet
2. You do not have hardware which supports reading the EVO using EcuFlash software
3. Did I mention the EVO is *not supported* in this version?

0. Ok. I tried to be as beta-tester - nothing more...
1. It's me clear... As far as I understood the new annonced Mitsu cable assumed that new s/w version will be issued?
2. You mean that there is no bit-bang mode in old openport cables?
I've tested s/w with selfmade hardware using 232R-chip.
3. I prefer to experience than sit and wait something...