Ecuflash Error/ECU Bricked?

Hello, I recently tried to get KSmods 1.03 running on my 7202 ecu. Got everything working but wanted to change the LC rpm, Changed it to 4499 and got error:
kernel flash enable
[11:41:09.196] kernel blank flash page: addr: 00020000
[11:41:24.301] WARNING: failed to erase page at 00020000!
[11:41:24.301] kernel flash disable
[11:41:26.315] interface close
I have pretty much tried everything at this point. Tried flashing every rom i have and know they work but it just cant seem to be able to erase that page. Has anyone encountered a similar problem and may be able to point me to a solution or is the ecu done?
Thanks, also attaching full log just in case.
Cant upload the log here since its too large, download it here: https://www.upload.ee/files/13471152/error.txt.html

Does the ECU still run the car at this point? Or is it totally dead?


Both myself and @foxdie have had ECU failures during flashing, which have rendered the ECU totally unusable - we don't know exactly what is causing it, but we *think* it's trying to reflash when the ECU is warm - for example if you've been driving the car hard, it's been sitting for a while with a hot exhaust, a long tuning session on the dyno etc, as the ECU is tucked up under the dash, on top of the transmission tunnel & exhaust, with no "natural" airflow to aid cooling.

I can't remember exactly the errors, but it might have been similar kinds of messages.

Or, it could just be that there's been too many changes flashed to the ECU - especially if you've been trying multiple things and have flashed it quite a lot.


I would probably say that your ECU is knackered, and you'll need a new one.

Hi @GregorEST - as Garry has asked, is the car running at this point?

The symptoms you describe are akin to EEPROM failure - it plagues flashing most factory ECU's at this point (which is why I keep spares when I'm tuning!).

There's 2 types of failure I've observed;

* Flashing failure towards the start of the EEPROM addresses, this results in a totally dead ECU you cannot fix
* Flashing failure towards the middle / end of the EEPROM addresses, can sometimes be recovered by flashing back the last good flashed ROM

If you can still flash, I would try flashing back the last successful ROM you programmed - hopefully you kept backups - that way the checksum should match and the ECU should start the car and drive.

In either case, you'll probably need a replacement ECU.

Keep an eye on the forum though, a couple of us have something in the works to provide a drop-in ViPEC / Link ECU where everything just works :)

Thanks for the responses guys, I haven't tried starting the car since as soon as I turn on the ignition the relays go crazy and also the rpm gauge jumps up and down. I tried flashing tons of roms that i know have worked but that aadress page seems to be done for. I guess its time to go haltech��

If you do decide to get a Haltech, you'll be starting from scratch, but if you go with a Link, then we've got lots of experience, and can help you massively get up and running!

As @foxdie says, keep an eye out because we're hoping that relatively soon, there'll be something available that'll make your life VERY easy to switch to an aftermarket ECU!

But at its current state you wouldn't recommend starting the car?

Quote:

---

Originally Posted by GregorEST

Thanks for the responses guys, I haven't tried starting the car since as soon as I turn on the ignition the relays go crazy and also the rpm gauge jumps up and down.

---

Yep, this is symptomatic of a bad flash - the ECU processor detects an invalid checksum on the EEPROM and doesn't boot up. When you flash the car, you're actually resetting the ECU and loading a custom program into it, hence why you can still start a flash process

Quote:

---

Originally Posted by GregorEST

I tried flashing tons of roms that i know have worked but that aadress page seems to be done for.

---

Sadly no, it needs to be the exact known-good flash that worked last time. Otherwise the checksum won't match.

Quote:

---

Originally Posted by GregorEST

I guess its time to go haltech��

---

As Garry has said, we can support you with a ViPEC / Link ECU, between Garry and myself we've got 8 years experience with them already and can support them ;)

Quote:

---

Originally Posted by GregorEST

But at its current state you wouldn't recommend starting the car?

---

If everything's clicking / going crazy that means the ECU isn't running the correct code and although the engine will turn over, there'll be no ignition / spark / fuel / anything.

Where abouts do you live btw?

I live in Estonia. My reason for going the path of Haltech is simple. Since i work in a company that has great contacts at haltech I can get a 2500 cheap. I'll be doing a full custom harness and dbw anyways so yeah. And we also have a tuner in house that has tuned everything from street cars to top of the line drag cars:)

Quote:

---

Originally Posted by GregorEST

I live in Estonia. My reason for going the path of Haltech is simple. Since i work in a company that has great contacts at haltech I can get a 2500 cheap. I'll be doing a full custom harness and dbw anyways so yeah. And we also have a tuner in house that has tuned everything from street cars to top of the line drag cars:)

---

Fair enough, best of luck then :)

Posted in your thread on OZVR4

Long story short, could be a bug in ECUFlash.
I usually correct it with older version of ECUFlash that uses virtual com for the openport, but the other variable is the reflash kernel version is older too.

https://www.ozvr4.com/threads/here-w...6/#post-356121

Also I believe plug in LinkECUs are already available. TME Motorsport been putting LinkECUs in VR4 for a while now, was under the impression they were plug in.
I'll ask when I speak to Steve next.

Quote:

---

Originally Posted by foxdie

Yep, this is symptomatic of a bad flash - the ECU processor detects an invalid checksum on the EEPROM and doesn't boot up. When you flash the car, you're actually resetting the ECU and loading a custom program into it, hence why you can still start a flash process

---

Not quite... that page is effectively empty so the processor is executing empty memory (ie program counter is still incrementing). Cos a whole page is missing, the whole rom/code doesn't run right.
Nothing to do with checksums, H8 isn't that complex ;)

There aren't any current Link boards that are plug & play direct from Link. It's possible that Steve has either 1) modified the Evo 4-8 bottom board, or 2) made a new base board, or 3) does wiring changes...? :)

Quote:

---

Originally Posted by foxdie

* Flashing failure towards the start of the EEPROM addresses, this results in a totally dead ECU you cannot fix
* Flashing failure towards the middle / end of the EEPROM addresses, can sometimes be recovered by flashing back the last good flashed ROM

---

To elaborate on this a bit

0x10000 to 0x101FF contain the vector table. This is critical for the H8 proc to boot as it tells the proc what address to jump to on first boot, errors, etc. If this is erased, then definitely would need to desolder the H8 and flash manually - or get another ecu.

0x20000 is the start if the reflash routine, again if this page is erased, might have tough time reflashing. This is the routine that the proc jumps to when voltage is present at the reflash connector, and allows the proc to load the reflash kernel into ram, them execute the kernel from ram to then reflash the rom. if there's nothing to let ecuflash upload the kernel to ram (i.e. the routine is not there), then again new ecu or desolder proc and reflash manually.

Fuel/ignition/bdel maps and all the other stuff that get tweaked are part of the same page as the vector table - which is a little dangerous if the reflash doesn't go well for that segment. In a 7202 this is segment/page LB7 (0x10000 to 0x12FFF)

Reflash routine is part of segment LB3 (0x2000 to 0x23FFF), which is code not data, so usually doesn't get modified unless you are flashing a different rom like KSMods or Halo.

7203 divides the segments differently, which is why the reflash is different and memmodel needs to be set correctly.

Any other areas of rom that are corrupt/erased wouldn’t affect the ability to reflash.

In the @GregorEST case, 0x20000 has attempted to erase, but failed. so the reflash routine might be still intact.

I have tried both ecuflash 1.44.4870 and 1.44.4799 but will give 1.38 a shot. Everything else flashes and completes perfectly. The problem only occurs in the 0x00020000 range.

Also i have 1998 so a 7202 and i use your defs @BCX.

Decided to keep the thread alive here, as per @BCX post at OZVR4 i uploaded the log to drive,
https://drive.google.com/file/d/1Gv9...ew?usp=sharing
If possible then @BCX you could send me the 1.41 installer and ill go give it a shot right away.
Thanks everyone

https://www.dropbox.com/s/ixawuttido...3_win.exe?dl=0

Here you go.

Im more active on ozvr4 than here, your post on there triggered me to check here lol.

Thanks!
But will i still override the read templates and defs with the ones you made?

If you're using the default location ie c:\program files... Then grab the rommetadata folder, then reinstall.

You can paste the folder back, or somewhere in ecuflash point to another folder for metadata.

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 installationAttachment 83189

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.

This is amazing @BCX @GregorEST - @foxdie maybe we can actually recover those ECUs we thought were dead!

Jeez, I blink and ALL THE POSTS! :D

Lot to cover here, forgive all the quotes!

Quote:

---

Originally Posted by BCX

Long story short, could be a bug in ECUFlash.

---

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.

Quote:

---

Originally Posted by BCX

Also I believe plug in LinkECUs are already available

---

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.

Quote:

---

Originally Posted by BCX

Not quite... that page is effectively empty so the processor is executing empty memory (ie program counter is still incrementing). Cos a whole page is missing, the whole rom/code doesn't run right.
Nothing to do with checksums, H8 isn't that complex ;)

---

Quote:

---

Originally Posted by BCX

To elaborate on this a bit

0x10000 to 0x10199 contain the vector table. This is critical for the H8 proc to boot as it tells the proc what address to jump to on first boot, errors, etc. If this is erased, then definitely would need to desolder the H8 and flash manually - or get another ecu.

0x20000 is the start if the reflash routine, again if this page is erased, might have tough time reflashing. This is the routine that the proc jumps to when voltage is present at the reflash connector, and allows the proc to load the reflash kernel into ram, them execute the kernel from ram to then reflash the rom. if there's nothing to let ecuflash upload the kernel to ram (i.e. the routine is not there), then again new ecu or desolder proc and reflash manually.

---

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 :D

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.

Quote:

---

Originally Posted by Confused

This is amazing @BCX @GregorEST - @foxdie maybe we can actually recover those ECUs we thought were dead!

---

I can give it a try for sure :)

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.

Attachment 83190

It's just writing that fails...

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

---

And with MMCFlash (which does the whole chip in one go);

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

---

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.

Quote:

---

Originally Posted by foxdie

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

---

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.

@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 :)