Okay uhh, so i have unistalled ecuflash 1.44 but cant seem to find an openport driver in device manager. Is there a different name for the driver or something?
EDIT: Nvm found it after plugging in the OP lol
Okay uhh, so i have unistalled ecuflash 1.44 but cant seem to find an openport driver in device manager. Is there a different name for the driver or something?
EDIT: Nvm found it after plugging in the OP lol
Cant quite get past this point for some reason, as soon as I plug in the OP it just installs the default drivers and if I don't plug it in it will still fail the driver installationOpenPort Device Installer 14_09_2021 18_50_20.png
I actually run a dedicated virtual machine with ecuflash 1.41 and use usb passthrough to the vm to reflash.
Ill have to try tomorrow going from 1.44 to 1.41 unless you work it out in the meantime.
Its 1:30am here and gotta work tomorrow.
No worries, good night!
In c:\program files... You can try get try pointing device manager to folder where drivers are?
THANKS BCX! Everything worked as a charm when i used 1.41. Got it running on a VM aswell and flashed right away and started right up. Now to get LC set up and were off again! Thanks again everyone.
So after all it ended up being a bug in the ecuflash software. If anyone in the future encounters the same problem:
1. Stay calm
2. Download EcuFlash 1.41 version
3. Get Windows 7 running on VirtualBOX
4. Install EcuFlash 1.41 on your Windows 7 machine
5. Via usb passthrough enable openport 2.0
6. Start ecuflash and try again(also make sure to use BCX definitions and read templates since 1.41 doesnt have them)
7. Try reading the ecu and if succeed try flashing it with the last known to work rom.
Also @BCX do you reccommend using 1.41 all the time or just when errors as such occur?
Thats fantastic news!
I use latest version of ecuflash for most stuff as its more robust when dealing with xml files with errors, etc but then switch to the VM when things dont go well.
Nothing stopping you using the vm fulltime for reflashing and editing, or edit with 1.44 then reflash with 1.41. Up to you. Never had 1.41 not successfully reflash.
Im used to use virtualbox, but switched over to VMware workstation, but same.
Ive only seen the issue with 7202 (which i use as my bench ecu and have reflashed over 300 times easy) but never had a problem with 7203 which my vr4 has.
When i get home, will document how to downgrade to 1.41 for someone who cant use a VM.
Jeez, I blink and ALL THE POSTS!
Lot to cover here, forgive all the quotes!
Indeed - I too have been running the latest EcuFlash on Windows 10, but I have been running MMCFlash (for the 7201 / H8/539F variants) on a Windows XP Virtualbox VM. I may try shifting EcuFlash and EvoScan into that VM too and keep them there.
As Garry said, there is 100% no (official) Link / ViPEC PnP board for the EC5A / EC5W, people have been taking Evo 4-8 boards and modding the base board.
We documented all the changes that are required (new wires, PCB trace cuts) but even then it's not perfect, so we have been designing one that'll literally take any ViPEC / Link G4 / Link G4+ / Link G4X top board.
Not only will these support factory features, they'll easily support additional modifications such as e-throttle and individual coil-on-plug.
We expect these to be available for sale (at a very competitive price because we want to help the community) within the next 30 days or so.
Some interesting information there. Firstly, I was under the strong belief the H8 was checksumming the EEPROM on boot. It makes sense that the vector table being screwed would cause it to f(l)ail and we see the IC randomly triggering outputs. I strongly believe this is because the watchdog timer is constantly firing and triggering the RES(ET) pin.
I'm unclear on the reflash procedure though. This is what I have learnt so far;
Pin 1 on the Mitsi 12-pin reflash connector is connected directly to the RESO/Vpp (watchdog / programming voltage) pin 19 on the H8/539F. It's also broken out on pin 6 on CON2 on the PCB for factory programming.
We know that when programming, we're uploading a Kernel into RAM to execute arbitrary (reflashing) code. It seemingly does this by first pulling RESO low (and by proxy, the RES pin) to reset the ECU and then immediately pulling it to 12V+ for programming.
When doing this, I also observed MD1 going high (12V) and through a logic level converter, this holds the RES pin high too. This puts the IC into Mode 4 or 7 (and by the truth table on page 513 of the H8/539F manual this implies we're in Boot mode in Mode 7).
At this point the H8/539F expects code to execute to be fed in via the SCI (serial communication interface) and is stored in RAM. This is done via K-Line asynchronously with the H8/539F controlling which pin (RXD1 or TXD1) the K-Line pin is connected.
Because of this, my belief is that it doesn't matter what is stored on the EEPROM, you should always be able to boot the H8/539F from a custom Kernel no matter if the EEPROM is dead or not. The whole premise of the H8/539F was they were supposed to be "unbrickable"... (don't think they factored in age / wear on that lol).
I have some old world RS232-based H8/539F programmers (F-ZTAT) and spare blank H8/539F IC's I've yet to play with. It's so old the software came on floppy disk. Still need to figure out how to use it
I tried desoldering a 7202 from a known-dead board with a hot air rework station but could not for the life of me get the damn thing to desolder / lift off the board.
The F-ZTAT connects directly to CON2 (this is how I managed to get information on CON2) but as yet, I have yet to successfully test it. I recently bought a laptop with a physicalised RS232 port (Getac V110, very nice) but am just waiting on some spare time to have a play.
I can give it a try for sure
Last edited by foxdie; 15-09-2021 at 01:41 PM.
Have questions about performance upgrades and ECU tuning? Before PM'ing me, Check this thread first
Please support CVR4 & become a Full member, you get a full years access to guides, games, chat & much more!
Sadly no such luck, this was attempting to flash a factory 7202 ROM image to a known-bad MH7202F (flashing dash lights / not booting) with the memmodel set in EcuFlash Version 1.41.2483 to MH7202F (doesn't seem to be possible to set it to the MH7203FA admittedly).
Reading the ECU is completely fine, although the ROM ID is garbage, opening it in a hex editor I can see the tables are there.
failed-rom-table-sample.png
It's just writing that fails...
And with MMCFlash (which does the whole chip in one go);Code:[14:29:43.530] J2534 API Version: 04.04 [14:29:43.530] J2534 DLL Version: 0.50.2464 Jan 29 2009 10:58:58 [14:29:43.530] Device Firmware Version: 1.16.4769 [14:29:45.452] sending init sequence 2 [14:29:45.468] got 0x11 response [14:29:45.468] sending init sequence 3 [14:29:45.905] entering bootloader [14:29:45.921] sending kernel size (1905) [14:29:45.937] sending kernel load address (0x0000F000) [14:29:45.968] uploading kernel [14:29:46.374] verifying kernel checksum response [14:29:46.374] kernel valid [14:29:46.577] kernel get version [14:29:46.593] kernel version is : OpenEcu Mitsubishi H8/539F Kernel V1.05 [14:29:46.593] reading kernel comm buffer size [14:29:46.624] comm buffer size set to 256 [14:29:46.624] reading kernel flash buffer size [14:29:46.640] flash buffer size set to 1024 [14:29:46.640] -- flashing image to ECU memory -- [14:29:47.046] -- comparing ECU flash memory pages to image file -- [14:29:47.046] seg start len ecu CRC32 img CRC32 same? [14:29:47.234] FB16 00010000 00003000 F1F68679 2E2EBCE5 NO [14:29:47.249] FB01 00013000 00000200 3C7B6428 BD7BC39F NO [14:29:47.280] FB02 00013200 00000200 2A7A11AE BD7BC39F NO [14:29:47.296] FB03 00013400 00000200 61F8D35F BD7BC39F NO [14:29:47.327] FB04 00013600 00000200 69C31D86 BD7BC39F NO [14:29:47.343] FB05 00013800 00000200 76F08B0F BD7BC39F NO [14:29:47.374] FB06 00013A00 00000200 BFA71F3D BD7BC39F NO [14:29:47.405] FB07 00013C00 00000200 6CBE8AAA BD7BC39F NO [14:29:47.421] FB08 00013E00 00000200 A4251092 BD7BC39F NO [14:29:47.640] FB15 00014000 00004000 01247645 F9428341 NO [14:29:47.843] FB14 00018000 00004000 21B10182 9C038689 NO [14:29:48.062] FB13 0001C000 00004000 690B37D3 690B37D3 YES [14:29:48.280] FB12 00020000 00004000 7FCEEBEA 3792E004 NO [14:29:48.499] FB11 00024000 00004000 1545D1AD 91DCA252 NO [14:29:48.718] FB10 00028000 00004000 A425DD39 B9B933F1 NO [14:29:48.937] FB09 0002C000 00004000 7E7F46B7 5B1A2299 NO [14:29:48.937] kernel flash enable [14:29:48.952] kernel blank flash page: addr: 0002C000 [14:29:48.999] erased in 1 pulse(s) [14:29:48.999] kernel write flash buffer addr: 0002C000 len: 00000100 [14:29:49.062] kernel write flash buffer addr: 0002C100 len: 00000100 [14:29:49.124] kernel write flash buffer addr: 0002C200 len: 00000100 [14:29:49.187] kernel write flash buffer addr: 0002C300 len: 00000100 [14:29:49.249] kernel commit flash addr: 0002C000 len: 00000400 crc32 72092293 [14:29:49.280] kernel debug: [14:29:49.280] [B0] FF FF 00 32 F9 4A 00 14 C0 00 F0 00 FF FF C0 7F 71 B8 02 [14:29:49.296] kernel error: programming failure [14:29:49.296] failed to commit flash at 0002C000! [14:29:49.296] failure in flashing block [14:29:49.296] kernel flash disable [14:29:49.312] interface close
Code:[14:36:15] File "E:\Car Tuning\EcuFlash\Default ROMS\Default VR-4 7202 and 7203 Auto Non-TCL - EM2428.hex" has been opened [14:36:17] Writing ROM [14:36:19] Boot [14:36:49] Boot OK [14:36:54] Boot [14:37:24] Boot OK [14:37:25] Erasing ROM [14:37:32] ERROR
Last edited by foxdie; 15-09-2021 at 02:47 PM.
In my whole time of writing code for the h8 ecus, never really looked into how ecuflash actually reflashes. Might dust off my logic analyser and oscilloscope.
The rom built-in reflash routine I've interacted with a few times and assumed this was how reflash took place. Flmcr is checked and jumps to section of code in 0x20000 segment. Will dig up my notes on this if your interested.
I stopped looking into reflash a long time ago as it was a distraction to writing goodies/new features.
Interesting there is documentation on con2. I self reversed engineered it and used it for additional telemetry like map input, oil temp/pressure, ethanol content, fuel temp/pressure. Revision 1 of my flex rom used rear o2 input but really wanted more adc inputs to implement more like failsafes, fuel pressure/temp compensation, etc.
Now theres a permanent comms channel open, I implemented live tuning. Reflash after each change was annoying.
Last edited by BCX; 15-09-2021 at 05:05 PM.
Looking at the output, definitely id say the chip is rooted.
If you're seeing behaviour/output like @GregorEST then it's more than likely the ecuflash bug.
Definitely interested in those notes @BCX - the more we all know the better
I do not claim to be an expert as I know we're all just scratching the surface.
I just dug out the FLASH1 and FLASH2 Z-TAT programmers I had and tried to write to the knackered 7202 chip;
FLASH1 Z-TAT with its own software would attempt to program but fail at the negotiating baud phase, but at least lights up the Vpp activity LED so I know it's *trying*.
FLASH1 Z-TAT with the FLASH2 software is initially detected but fails to erase a flash page, I note the Vpp does not light up, checking the software it only supports the H8-539A and 539S, not the 539F.
FLASH2 Z-TAT doesn't appear compatible whatsoever, I'd have to build up a cable and then it likely won't work.
Best guess here is it should be the FLASH1 Z-TAT with its own software, however the on-PCB circuitry to convert to K-Line comms is fouling the use of the CON2 port. Unless you know of something?
All of that info on that CON2 port Google Sheets link was also self-reverse engineered by myself using an old Tektronix THS720P. Bit of an old unit but still seems to work
This is a good resource for the built in reflash routine.
http://www.kaele.com/~kashima/car/evo/
I stumbled across this back in the day when doing research about it all. The disassembly confirms how he's described it.
Last edited by BCX; 15-09-2021 at 05:28 PM.
@BCX will live tuning features be public in the nearest future or are you still in the testing phase? Also i would like to ask about project HALO(project made it sound cooler) what is it and is it open to public aswell?
Thanks for the link Bill, haven't had chance to properly digest the information yet (day job stress) but skim reading it is rather juicy.
If that page is correct about disabling boot mode flashing then that's a real shame. I was hoping to try and coax those dead cells back to life by repeatedly hammering them with 0xFF and 0x00. Definitely not guaranteed to fix the issue but worth a shot just in case.
Also tempted to write my own reflashing program and put it on Github or something for others to judge me.. er contribute to