openecu.org

I have heard from a number of people that the new ecuflash if using the existing xml files, that the new ecuflash crashes with illegal operations on startup. microsoft windows best practise states that all errors should be handled by a global Main STA thread error handler and exit gracefully. If you could add an xml parser error message, that could point to the troublesome xml files in existance created by previous versions of ecuflash.

ECUFlash 1.30 does not seem to start up at all for me. I originally installed over the top of 1.29a, which didn't work, then I uninstalled everything, deleted all old data and definitions, reinstalled, and it still doesn't start up.

I'm sure a fix will be coming soon, but just letting you know. FYI I am running Windows 2000 SP4 on PIV.

No problems here. Installed fine, ran fine. XP Pro.

bpi wrote:ECUFlash 1.30 does not seem to start up at all for me. I originally installed over the top of 1.29a, which didn't work, then I uninstalled everything, deleted all old data and definitions, reinstalled, and it still doesn't start up.

I'm sure a fix will be coming soon, but just letting you know. FYI I am running Windows 2000 SP4 on PIV.

As Colby has said on other threads, Win2K is a bit hit and miss, and I doubt that he is loosing much sleep over compatibility issues with an obsolete operating system (flame suit on!)

I'm running winXp, it has some illegal operations sometimes.

Do you have the most recent ".net", "java", and "QT' releases?

I had issues with EVERTHING! till I updated the "background programs" (at the lack of a better description).

I also reinstall the OS every year and sometimes more if there are sensitive projects that do not need, "Sorry, but windows had to close this ??? program", or the famous "blue screen of death".

anyone have version 1.28 or 1.29??? i cannot run 1.30 on my budget win2k laptop lol....

Evo4Mad wrote:I have heard from a number of people that the new ecuflash if using the existing xml files, that the new ecuflash crashes with illegal operations on startup. microsoft windows best practise states that all errors should be handled by a global Main STA thread error handler and exit gracefully. If you could add an xml parser error message, that could point to the troublesome xml files in existance created by previous versions of ecuflash.

nothing has changed about the XML parsing at this point. if anyone can provide specifics about a crash, i would be happy to look into it. it will be changing the XML parsing error reporting soon to be more helpful.

colby

also, EcuFlash compiles in Qt as a static library, so there should be no versioning issues with Qt DLLs you may have on your system - it is not using those.

cobly

does not work for me too. cannot even start and i am too on win2k sp4

I finally got around to installing 1.30 and it will not start. Hourglass comes up for a split second, but the program does not start. No error.

I spent a good hour and a half uninstalling, reinstalling, eventually trying to manually clear out the drivers by hand to make sure they really went away after further uninstalling, rebooting, and reinstalling.

I don't know what is wrong.

This is my case:
car is a MY05 WRX UK spec / EDM.
I hv plug the green connector.

when I use ecuflash 1.29a, I got this:
[00:14:39.905] Version 1.29.906
[00:14:39.915] 8 memory models read.
[00:14:42.739] 142 ROM metadata models read.
[00:14:42.739] checksum module "subarudbw" loaded.
[00:14:42.739] flashing tool "wrx02" loaded.
[00:14:42.749] flashing tool "wrx04" loaded.
[00:14:42.749] flashing tool "sti04" loaded.
[00:14:42.749] flashing tool "sti05" loaded.
[00:14:42.749] flashing tool "mitsukernel" loaded.
[00:14:42.749] flashing tool "mitsukernelocp" loaded.
[00:14:42.749] flashing tool "mitsubootloader" loaded.
[00:14:55.918] ssm2_init
[00:14:56.088] ECU ID is 3D 44 58 30 05
[00:14:56.088] ssm2_cmd_0x81

it stop there.

then I uninstall program & drivers. reboot then install the 1.3, I got this:
[01:12:46.088] Version 1.30.1095
[01:12:46.098] 8 memory models read.
[01:12:48.932] 146 ROM metadata models read.
[01:12:48.932] checksum module "subarudbw" loaded.
[01:12:48.932] flashing tool "wrx02" loaded.
[01:12:48.932] flashing tool "wrx04" loaded.
[01:12:48.932] flashing tool "sti04" loaded.
[01:12:48.932] flashing tool "sti05" loaded.
[01:12:48.932] flashing tool "mitsukernel" loaded.
[01:12:48.932] flashing tool "mitsukernelocp" loaded.
[01:12:48.932] flashing tool "mitsubootloader" loaded.
[01:12:54.690] SSM2 init
[01:12:54.870] [FF] A2 10 0F 3D 44 58 30 05 73 FA EB 80 2B C3 02 AA
00 10 00 60 CE 54 FC B0 60 00 00 E0 00 00 00 00
00 DC 00 00 55 1F 00 00 02 02 00 00 00 00 00 E0
00 00 00 00 00 00 00 00
[01:12:54.890] SSM2 ECU ID is 3D 44 58 30 05
[01:12:54.890] SSM2 cmd_0x81

it stop there.

So may I know what happen? is the ECU stop the PC to from reading it or we need a better ver., of ecuflash...??

I'm using WinXP Home.
TQ

Freon wrote:I finally got around to installing 1.30 and it will not start. Hourglass comes up for a split second, but the program does not start. No error.

I spent a good hour and a half uninstalling, reinstalling, eventually trying to manually clear out the drivers by hand to make sure they really went away after further uninstalling, rebooting, and reinstalling.

I don't know what is wrong.

This is exactly the same problem I am facing!!! You on win2K as well? I got it to work on xp and not win2K. Hoping that it will work on win2k as my office notebook is on that. If i need a xp means i need to get one myself

I have this running on 2 PCs, both on XP Pro; on one it was seamless, installed and ran fine. On the other, it installed ok, and even ran ok. But when I plug an OpenPort cable in, it freezes.

It's an interesting 'freeze': Task Manager can't kill the process, but the ECUFlash window can still be moved / minimised etc.

Here's the biggest giveaway: when in Device Manager trying to view 'Properties' on the USB Controllers -> OpenPort 1.3 Mitsubishi, it freezes then too, I mean, like, forever. You can't kill the process.

So in my case at least, I believe it is a driver probem, perhaps something like a DLL version mismatch; who knows how! Then again, FTDI chips are pretty common, and there are probably lots of apps using their driver files. Perhaps the driver install thing needs to be a bit more 'independent' of other FTDI drivers.

OK will try on another notebook... see if the same problem I hv...