Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Bricked ecu members(need your help)...........clone from 99vr4(Brett)

  1. #11
    I lack color... verified

    Join Date
    Sep 2010
    Owner Since
    Aug 1998

    Posts
    3,589
    Thanks
    104
    Thanked 498 Times in 241 Posts
    Quote Originally Posted by 99 vr4 View Post
    and I already know if you open up the bin file and change some characters in hex editor and save it it will still open n ecu flash, yet when you flash it can f*** it up
    No you don't know this. If you flash a ROM with bad code, the car just doesn't start. Done this dozens and dozens of times testing beta code.

    ECUFlash can write lady gaga onto our ECUs and it won't brick the ECU. If the XML for Lady Gaga has the "F" memory model tagged inside itll write it to the ECU without bricking. ECUFlash is the program that controls the flash. The ROM is nothing more than operational parameters writen inside.
    Last edited by Greg E; 01-31-2013 at 06:40 PM.

    2014 Exomotive Exocet - #101 "shocker yellow" - 1.8L 5-speed 3.9 torsen FMII powered
    Read more: http://mevowners.proboards.com/threa.../greg-pa-build

    99 Solano Black VR4 - #16 of 287 - ground up restoration - sold
    98 Pearl White VR4 #54 of 231 - 12.84@105mph - 93 Octane 12.50@107mph - 100 Octane with Chromed ECU - sold
    99 Pearl White VR4 #108 of 287 - 3RD place stock car class ECG 11 - Sold
    98 Black VR4: 100% stock - totalled by an Illegal 2-12-08
    95 White Stealth TT - 11.852 @ 118.25 - sold
    95 SSG Stealth TT - 11.981 @ 115.81mph - sold

    "I don't actually work on cars, I just talk about them on the internet."

  2. #12
    Forum User Not Verified

    Join Date
    Sep 2010
    Owner Since
    2004

    Location
    Cape Girardeau
    Posts
    4,791
    Thanks
    365
    Thanked 296 Times in 214 Posts
    winmerge is an excellent tool for comparisons

    Parting 6 speed
    Pampena 3.5 Stroker, GTX 2867 Gen IIs, AEM Series2, oohnoo SMIC, DN Hardpipes, FIC 1650s, Walbro 525, aermotive fpr, Dejon intake pipes, Tial Q, Koyo Rad, Samco Hoses, Stoptech 332mm fronts, HKS GT4 Coilovers, Spec 4+ LW, JDM 6 Speed, Billet shift forks, Pampena brace

  3. #13
    I lack color... verified

    Join Date
    Sep 2010
    Owner Since
    Aug 1998

    Posts
    3,589
    Thanks
    104
    Thanked 498 Times in 241 Posts
    Quote Originally Posted by Forest Gump View Post
    winmerge is an excellent tool for comparisons
    Lots of programs can do this. I chose to use excel because it was simple to setup with the vlookup function.

  4. #14
    Forum User verified
    Join Date
    Oct 2010
    Owner Since
    1993

    Location
    St Louis
    Posts
    343
    Thanks
    29
    Thanked 48 Times in 31 Posts
    Quote Originally Posted by Greg E View Post
    Please don't start spreading these rediculous ideas.

    Flashing a different stock ROM to an ECU (read off a stock VR4 ECU and saved onto the hard drive) can cause a bricked ECU. Even trying to write the stock 99 VR4 006 ROM onto an earlier VR4 ECU with the 004 file on it can cause a brick. Its happened to me many times before I even got into ROM mods. I highly highly doubt somehow this ROM could become corrupt reading, saving to the HD and writing to another ECU. I don't even have a SSD HD on my laptop.

    Luckily I had success in unbricking these ECUs (all of these are true 98/99 boards before the idea of cloning was first discussed) by re-writing the original ROM back onto them.

    Bricks are caused from the battery losing a charge during a long flash. This isn't some idea I pulled out of the air.... I observe the battery drain on the volt meter gauge in my SL during a long flash. Scary to watch. I've even attached a real multimeter to observe the drain right off the battery itself during a flash. The voltage can drop as low as 10volts during a long flash! Try it for yourself.

    In fact I'll even go so far as to do a byte by byte comparison to this so called "bad rom" next to an original and show you the file does not become corrupted in anyway from being zipped. I wrote an excell file to do such a thing years ago now to find all the differences between the 3 known 99 ROMs I've found.
    Quote Originally Posted by Greg E View Post
    No you don't know this. If you flash a ROM with bad code, the car just doesn't start. Done this dozens and dozens of times testing beta code.

    ECUFlash can write lady gaga onto our ECUs and it won't brick the ECU. If the XML for Lady Gaga has the "F" memory model tagged inside itll write it to the ECU without bricking. ECUFlash is the program that controls the flash. The ROM is nothing more than operational parameters writen inside.
    Ok calm down Greg, your being sensitive dude. And you need to read carefully because you’re reading what you want to, not necessarily what I wrote.

    Even by your own admissions, there are MANY things that can cause a brick. The CPU inside the ECU is rated at 100 flash cycles. Your mileage may, and WILL vary.

    And I know, as I have tested it, that bad code flashed to the CPU can screw it up. What I am referring to is non readable characters that are beyond the ASCII readable table. Normally, the CPU will accept whatever you flash to it, even the freaking bible, without an issue, and then when you re-flash, it takes the new flash and erases what you flashed. But there is a section of the ROM which could be re-written which will prevent the ROM from re-flashing (write protection here, but this was not this case). And then there is the section of the ROM which is used for the boot loader. Yes, that can also be re-written. That is the ONLY section which NEVER changes between the Mitsubishi ROMs, and co-incidentally, is the only section populated in brand new un-flashed CPUs, and is also, co-incidentally, the area that always hangs on the brick . . . hmmmmmmmm

    So, yes, a really fucked up BIN, or a BIN fucked in the right spot, could (READ COULD, BUT NOT ALWAYS, AND NOT USUALLY) brick a CPU. Overall, this is not a serious enough issue to warrant requiring everyone to use a hash checker, but something you should not outright discount because you BELIEVE THAT THE ONLY thing that can brick a CPU is low voltage. After all, you were there, right? Oh wait, no you weren’t. And I ALWAYS keep an open mind. So in order to be 100% thorough, I decided to ask for his BIN and XML so that I could put that idea to bed.

    Off my soapbox.
    www.ClonedECU.com
    The home of the Original Clone and Clone2 ECU!
    More Plug n' Drive and less Plug n' Fail like the others!
    Remember, if it's not a Clone, it's just a copy!

    Get Chromed!
    Donate Now and receive a coupon code for the amount of your donation (up to $50.00 US) which you can apply at check out for a Clone2 ECU, Plug n’ Play Harness, or Clone2 Plug n’ Play Package!!
    1999 3000GT VR4
    Glacier Pearl White
    Yeah it's stock . . . trust me
    How To Contact Me:
    eMail: brett_farnam@yahoo.com
    US3S/3SGTO: 99 vr4
    3SI: bfarnam

  5. #15
    Forum User Not Verified

    Join Date
    Sep 2010
    Owner Since
    2004

    Location
    Cape Girardeau
    Posts
    4,791
    Thanks
    365
    Thanked 296 Times in 214 Posts
    Just to be clear, I'm not arguing anything, but why would the flash boostrap be overwitten anyway, since ECU Flash only writes things that are changed? Is it a block size problem? Changes are made in the same segment as the flash boot loader, even if that loader isn't changed it then overwrites the whole segment?

  6. #16
    I lack color... verified

    Join Date
    Sep 2010
    Owner Since
    Aug 1998

    Posts
    3,589
    Thanks
    104
    Thanked 498 Times in 241 Posts
    Quote Originally Posted by 99 vr4 View Post
    Ok calm down Greg, your being sensitive dude. And you need to read carefully because you’re reading what you want to, not necessarily what I wrote.
    No, this isn't be pulling an Adam. This is just simply me disagreeing with you as well as putting the claim to rest that somehow chrome itself can brick an ECU.

    Quote Originally Posted by 99 vr4 View Post
    So, yes, a really fucked up BIN, or a BIN fucked in the right spot, could (READ COULD, BUT NOT ALWAYS, AND NOT USUALLY) brick a CPU.
    Lady Gaga could fall in love with me for making my ECU sing her songs too. All kinds of stuff can happen in life at any random times. Maybe I should put the holy bible over my laptop and have God bless my PC in an attempt to prevent random chance from corrupting my ROMs and bricking the ECU too.

    ...but you're right. Maybe our friend Fridaythe13Th is indeed one of those unlucky guys who happened to find himself trapped in the circumstance of getting struck by lightning 3 times in the same spot. He is, after-all, named after the unluckiest day of the month...

    That just sounds ridiculous doesn't it? Not sure where this non-sense comes from but let's talk reality instead of probability for a moment.

    The more likely event is our friend Donald here tried to flash an ECU with either a tired battery or too much draw on the battery and bricked his ECU during the LONG initial flash of the V2 ROM. I can make this bet with such confidence as that has been the cause of every single bricked ECU I've experienced in the last 2 years and 500 or so flashes. I can even demonstrate this on video if you need to see it first hand (since apparently my word and experience isn't good enough).

    Now let's talk flashing. I am pretty sure you know this already but most people reading this do not AND for some reason you have taken this to a level of stating what I already know and twisting it around in such a way as to make your claim seem plausible.

    First ECUFlash divides the ROM into 12 segments then compares those segment to what is already writen onto the chips memory. Instead of writing the whole ROM into memory, it only rewrites what is different by comparison to the new ROM you're trying to flash. Pretty neat feature. Not only saves time during the flash, but also increase the life of the memory chip because (as you stated) it's only rated for 100 flashes.

    Now, first thing ECUFlash has to do is erase that segment. It does this by applying a super high voltage (about 16V) to the segment on the chip which is even higher than that of an erased memory cell. This causes all the electrons to tunnel out into something called a floating gate. After the section of memory is whipped out, ECUFlash drops the voltage.

    Now, a memory cell is read like an EPROM cell by driving the gate to the high level and detecting the drain current (which depends on the threshold voltage initially used to wipe out the memory segment). If your memory segment is "over erased" or your voltage source drops, its threshold voltage may become negative, causing the cell to operate incorrectly. When you go to write the new ROM into that segment, the 1's and 0's aren't really what the BUS reads as 1's and 0's anymore so the code literally becomes garbage and your ECU doesn't know how to operate itself anymore.

    It's like when you're building a wall and you use a 12' measuring stick for one side, and it shrinks to a 10' stick by the time you get to the other side. Your wall is junk and looks like it was assembled by a drunk man.

    Oh yeah, I know all too well about the (very very unlikely event) ASCII code becoming corrupt but that happens for the same reasoning as the corrupted memory segment. Mis-matched threshold voltages during flashing. The Boot Loader area of a stock ROM and Chrome are exactly the same! There is no other way this could get messed up.

    That doesn't negate my claim at all about NEEDING a strong battery source. I'm sure sometime in the future I'll stumble across an event where this happens but in the grand scheme that will quite literally be 1 in 500 flashes I've performed in my lifetime (so far) where that event occurred. That's not enough of a probably to get me to raise a caution flag at this project and try to come up with a better method of tuning.

    The simple fact is constant and steady battery voltage is the #1 key to ensuring a good flash every single time. Any person who bricks an ECU will owe me a taco when I go thru the motions of re-creating the event that cause the brick because every single time it's happened has been because of battery voltage drain.



    The source of information from this post comes from the H8 extended technical manual written by Hitachi for the CPUs used in our ECUs written on page 524 which can be viewed here:

    http://evoecu.logic.net/mirror/cpudo...20extended.pdf
    Last edited by Greg E; 01-31-2013 at 10:38 PM.

  7. #17
    I lack color... verified

    Join Date
    Sep 2010
    Owner Since
    Aug 1998

    Posts
    3,589
    Thanks
    104
    Thanked 498 Times in 241 Posts
    Quote Originally Posted by Forest Gump View Post
    Just to be clear, I'm not arguing anything, but why would the flash boostrap be overwitten anyway, since ECU Flash only writes things that are changed? Is it a block size problem? Changes are made in the same segment as the flash boot loader, even if that loader isn't changed it then overwrites the whole segment?
    If your XML tells ECUFlash to write the ROM according to a different memory model, it's entire map of the chip is completely off. You can get lucky sometimes by trying to rewite exactly what was over-written into memory but that's a luck of the draw.

    Brett is claiming that this event was the result of a corrupted download. But we know that not to be the case because Friday posted the XML header and it showed the correct memory model. ECUFlash would not have been able to open the .bin file if it was corrupted.

    Quote Originally Posted by 99VR4
    I download tons of files from the internet and every now and then I'll get a corrupted download. it happens. it will have the right file size but 1 character somewhere in the middle be screwed up in the exe or zip won't run.
    If battery voltage was absolutely without a doubt strong and steady, I'm more opt to believe it was just the CPU's time to die from an improper erase.
    Last edited by Greg E; 01-31-2013 at 10:09 PM.

  8. #18
    Forum User verified
    Join Date
    Oct 2010
    Owner Since
    1993

    Location
    St Louis
    Posts
    343
    Thanks
    29
    Thanked 48 Times in 31 Posts
    Greg, first off, I have plenty of bin files that I can open to flash, but the xml does not match so I can't edit.... You can open a bin with a bad xml... I can send you one if you want to see for your self. These are mostly the obscure ROMs that I pull of random ECUs and tell ECU Flash that it is based off of a VR4.... So all you get is the header.... Nothing else opens or works... But I can still flash it, right or wrong

    The H8 only requires +12v on Vpp and the mode Pins to flash. The 16 volts (17.1 on my tactrix) is a design of the Mitsubishi ECU to prevent an accidental flash. There is more to that circuit than you realize...

    The H8 uses standard flash memory plus a ROM and a RAM segment.... No incredible draw on the actual chip level., it's not like an EEPROM Check the quoted manual again. I don't have the time to re phrase what is written by Renaseas...

    And to set this straight, I never said Chrome caused the brick... I am saying that it is possible that a corrupted download caused this. Poor Donald had a new battery and a fully charged jump start box. And he was unable to open up the bin after the bad flash.... You tell me.

    Donald texted me and thought maybe ECU.Flash had caused this.... I said very unlikely

    And to be clear, the boot area of the ROM, if corrupted in the BIN, will be flashed by ECU Flash because it is different.... correct?

    So in closing why are you being so defensive?

    Are you pulling an Adam?

    It's a lot easier to admit that yes, how ever unlucky and improbable, Donald could have had a bad download which caused this problem. This in no way places blame on any one other than the internet. But you would rather argue how it is easier to get struck by lightning that admit that... Why?

    I think that it is just as important to tell people to verify their downloads ad it is to tell people that they need to have a battery charger....

    Call me if you want to discuss this further...

  9. #19
    I lack color... verified

    Join Date
    Sep 2010
    Owner Since
    Aug 1998

    Posts
    3,589
    Thanks
    104
    Thanked 498 Times in 241 Posts
    Quote Originally Posted by 99 vr4 View Post
    It's a lot easier to admit that yes, how ever unlucky and improbable, Donald could have had a bad download which caused this problem. This in no way places blame on any one other than the internet. But you would rather argue how it is easier to get struck by lightning that admit that... Why?

    I think that it is just as important to tell people to verify their downloads ad it is to tell people that they need to have a battery charger....

    Call me if you want to discuss this further...
    Yes but if the header section of the ROM was corrupt, ECUFlash wouldn't even be able to open it. The header must have been fine otherwise he never would have been able to get to the flashing stage to begin with. Well no... That's not entirely true. ECUFlash will just pop up with a message saying "unknown image". If he would have tried to flash that, I can see it causing the brick.

    I'm however much more opt to believe one of the memory segments on his particular ECU went bad due to a hardware issue on his particular board. That's all I'm saying. Just trying hard to avoid people panicking over something that has a great chance of NOT happening.

    Sorry I can't call. Girl is demanding my attention. I do want to talk to you though (about other things). Make up phone sex tomorrow morning?
    Last edited by Greg E; 01-31-2013 at 11:16 PM.

  10. #20
    It could have been just plan old bad luck, it was a 98 sl ecu from a unknown junk yard down in Florida. The Florida humidity could have got to it and it was just its time to take a crap. The world may never know lol. One thing I do know.......... I will never attempt a flash on friday the 13th because it will be brick city

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
The 3000GT/Stealth/GTO Web History Project
3000gt.com
3000GT / Stealth International WWWboard Archive
Jim's (RED3KGT) Reststop
3000GT/Stealth/GTO Information and Resources
Team 3S
3000GT / Stealth / GTO Information
daveblack.net
3000GT/Stealth/GTO Clubs and Groups
Michigan 3S
MInnesota 3S
Wisconsin 3S
Iowa, Nebraska, Kansas 3S
North California 3000GT/Stealth
United Society of 3S Owners
3000GT/Stealth/GTO Forums
3000GT/Stealth International
3000GT/Stealth/GTO Event Pages
3S National Gathering
East Coast Gathering
Upper Mid-West Gathering
Blue Ridge Gathering