Page 2 of 2 FirstFirst 12
Results 21 to 37 of 37

Thread: Ecuflash Error/ECU Bricked?

  1. #21

    Offline
     
    Name
    Gregor
    Join Date
    Nov 2020
    Last Online
    16-09-2021
    Posts
    19
    Country
    England
     
    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

  2. #22

    Offline
     
    Name
    Gregor
    Join Date
    Nov 2020
    Last Online
    16-09-2021
    Posts
    19
    Country
    England
     
    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

  3. #23

    Offline
     
    Name
    Bill
    Join Date
    Aug 2010
    Last Online
    Yesterday
    Posts
    150
    Country
    Australia
    Car
    2000 Galant
     
    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.

  4. #24

    Offline
     
    Name
    Gregor
    Join Date
    Nov 2020
    Last Online
    16-09-2021
    Posts
    19
    Country
    England
     
    No worries, good night!

  5. #25

    Offline
     
    Name
    Bill
    Join Date
    Aug 2010
    Last Online
    Yesterday
    Posts
    150
    Country
    Australia
    Car
    2000 Galant
     
    In c:\program files... You can try get try pointing device manager to folder where drivers are?

  6. #26

    Offline
     
    Name
    Gregor
    Join Date
    Nov 2020
    Last Online
    16-09-2021
    Posts
    19
    Country
    England
     
    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.

  7. #27

    Offline
     
    Name
    Gregor
    Join Date
    Nov 2020
    Last Online
    16-09-2021
    Posts
    19
    Country
    England
     
    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?

  8. #28

    Offline
     
    Name
    Bill
    Join Date
    Aug 2010
    Last Online
    Yesterday
    Posts
    150
    Country
    Australia
    Car
    2000 Galant
     
    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.

  9. #29
    Confused's Avatar

    Offline
     
    Name
    Garry
    Join Date
    Apr 2005
    Last Online
    Today
    Membership ID
    714
    Posts
    3,295
    Country
    United Kingdom
    Location
    Notts
    Car
    Legnum VR-4
    My Garage
    Visit
     
    This is amazing @BCX @GregorEST - @foxdie maybe we can actually recover those ECUs we thought were dead!

  10. #30
    foxdie's Avatar

    Offline
     
    Name
    Jason
    Join Date
    Jan 2008
    Last Online
    20-09-2021
    Membership ID
    518
    Posts
    5,027
    Country
    United Kingdom
    Location
    Birmingham, UK
    Car
    Silver PFL VR4
    My Garage
    Visit
     
    Jeez, I blink and ALL THE POSTS!

    Lot to cover here, forgive all the quotes!

    Quote Originally Posted by BCX View Post
    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 View Post
    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 View Post
    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 View Post
    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

    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 View Post
    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
    Last edited by foxdie; 15-09-2021 at 01:41 PM.
    Want your car tuning? Here's my pricing
    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!

  11. #31
    foxdie's Avatar

    Offline
     
    Name
    Jason
    Join Date
    Jan 2008
    Last Online
    20-09-2021
    Membership ID
    518
    Posts
    5,027
    Country
    United Kingdom
    Location
    Birmingham, UK
    Car
    Silver PFL VR4
    My Garage
    Visit
     
    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...

    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
    Last edited by foxdie; 15-09-2021 at 02:47 PM.

  12. #32

    Offline
     
    Name
    Bill
    Join Date
    Aug 2010
    Last Online
    Yesterday
    Posts
    150
    Country
    Australia
    Car
    2000 Galant
     
    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.

  13. #33

    Offline
     
    Name
    Bill
    Join Date
    Aug 2010
    Last Online
    Yesterday
    Posts
    150
    Country
    Australia
    Car
    2000 Galant
     
    Quote Originally Posted by foxdie View Post
    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.

  14. #34
    foxdie's Avatar

    Offline
     
    Name
    Jason
    Join Date
    Jan 2008
    Last Online
    20-09-2021
    Membership ID
    518
    Posts
    5,027
    Country
    United Kingdom
    Location
    Birmingham, UK
    Car
    Silver PFL VR4
    My Garage
    Visit
     
    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

  15. #35

    Offline
     
    Name
    Bill
    Join Date
    Aug 2010
    Last Online
    Yesterday
    Posts
    150
    Country
    Australia
    Car
    2000 Galant
     
    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.

  16. #36

    Offline
     
    Name
    Gregor
    Join Date
    Nov 2020
    Last Online
    16-09-2021
    Posts
    19
    Country
    England
     
    @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?

  17. #37
    foxdie's Avatar

    Offline
     
    Name
    Jason
    Join Date
    Jan 2008
    Last Online
    20-09-2021
    Membership ID
    518
    Posts
    5,027
    Country
    United Kingdom
    Location
    Birmingham, UK
    Car
    Silver PFL VR4
    My Garage
    Visit
     
    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

Page 2 of 2 FirstFirst 12

Similar Threads

  1. Ecuflash error?
    By FTunedAU in forum ECUs / Mapping
    Replies: 2
    Last Post: 19-06-2021, 07:21 PM
  2. ECUflash for v6 N/A
    By lateshow in forum Performance Mods
    Replies: 74
    Last Post: 17-08-2016, 09:31 PM
  3. Help using ecuflash
    By rajvr497 in forum General / Questions
    Replies: 5
    Last Post: 19-06-2013, 07:11 AM
  4. EcuFlash
    By ayebalpaul in forum ECUs / Mapping
    Replies: 12
    Last Post: 28-02-2012, 01:00 AM
  5. ecuflash .bin file (need xml)
    By zentac in forum ECUs / Mapping
    Replies: 12
    Last Post: 04-06-2011, 08:57 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •