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

[fridayda13th]

Just giving props where props are due. He hooked me up with a clone ecu after I bricked my ecu his work is top notch. This clone smells and looks brand new, well that's because it is brand new.

I successfully flashed my car with v2, I used a car battery jump pack it was putting out 15 volts when I tested it with my voltmeter. My battery is a Wal-Mart brand (not sure which one) that has 700 cca and got it 8/12. Brett is trying to collect info on bricked ecu set-ups so we can eliminate this problem. So if you have bricked your ecu please post up your battery age, cca, brand, and if you used a jump pack or battery charger. Also if you jump pack was fully charged (it should be for flashing)

Oh and if you have bricked your ecu and need it fixed or need a new clone please Pm 99v4r (Brett). I do not work for him or anything like that, I just appreciate good people. :Clap:

[ChargerX3]

Glad you got it fixed. How is she running?

[fridayda13th]

I just let it idle, but its idling way better than it was on the one beat up ecu I had. AFR are the same about 14.5 to 14.4 that needs to be fine tuned a little. So far so good. Ill play with it more this weekend when the wife and baby are sleeping.

[Greg E]

You're not going to be able to fine tune idle. Might as well disregard the wideband entirely until you're in open loop.

Very glad to hear you're happy with the ECU repair!

[99 vr4]

Thank you for the props! The battery information is great! After testing you the other day, I am not sure if perhaps you had a bad xml that caused the brick. Hmmmm... could you maybe send me the "original" download package that you used so that I can check the CRC on it?

[Greg E]

Brett fail... :p

If the XML is "bad" ECUFlash won't even open it. The only way you can brick an ECU with a ROM is by trying to flash chrome onto an FA processor (or some other chip with a different memory model)

[fridayda13th]

I deleted the one that didn't open so I didn't get mixed up between the good and bad. It opened and started to flash just fine. It stopped at like 45% and gave me the error. I sent Brett the ecu received my clone back, put it in the car and tried to read from the ecu and it wouldn't read. So I went back in the house and tried to open the bin. and it wouldn't open. I played with ecuflash 1.44 then 1.42 and neither worked. I even thought it was my laptop so I tried my wives computer and still didn't work. So I found a evo bin(http://www.evoscan.com/roms/mitsubishi/) and it opened just fine. So the only thing it could have been was the xml.

[Greg E]

I deleted the one that didn't open so I didn't get mixed up between the good and bad. It opened and started to flash just fine. It stopped at like 45% and gave me the error.

That's because it lost voltage during the flash. Nothing to do with the ROM.

[99 vr4]

Greg, I think he could have had a corrupted file...a bad character some where in the bin would cause this.

This of why I posted the CRC/MD5 hash values for the other bin files.

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.

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

so it is quite possible he had an issue with his laptop that corrupted the file and caused the ecu to brick... this is why I asked for a copy of it to verify the hash value.

PC manufactures used to make sure you verify the hash every single time you try to update the BIOS on your PC for this very same reason.

it's nothing you did it just happens that way from time to time I think. the only way to know for sure is to verify the XML and bin, which of course he does not have any more

Just saying.

[Greg E]

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.

[Greg E]

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.

[Chris@Rvengeperformance]

winmerge is an excellent tool for comparisons

[Greg E]

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.

[99 vr4]

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.


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.

[Chris@Rvengeperformance]

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?

[Greg E]

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.


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/cpudocs/h8539f/H8%20539%20extended.pdf

[Greg E]

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.


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.

[99 vr4]

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...

[Greg E]

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

[fridayda13th]

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

[Greg E]

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

:lol:

I'm really surprised Brett was quick to assume a corrupt download instead of a bad core ECU. He's the guy who rarely accepts core ECUs because of all the issues that come from a 15 year old micro-controllers.

[ChargerX3]

Both possibilities seem miniscule. Gregs file being corrupt would be less so. I've flashed my ecu's many times and without a charger and on a low battery. Luckily I haven't bricked anything yet, but that is why I have a test ecu that I always preflash my rom to. Just in case something somewhere goes wrong.

I would suggest everyone who flashes gets a battery charger to ensure a proper flash. Not worth having to go back and fix a brick.

[BucknVr4]

Both possibilities seem miniscule. Gregs file being corrupt would be less so. I've flashed my ecu's many times and without a charger and on a low battery. Luckily I haven't bricked anything yet, but that is why I have a test ecu that I always preflash my rom to. Just in case something somewhere goes wrong.

I would suggest everyone who flashes gets a battery charger to ensure a proper flash. Not worth having to go back and fix a brick.

So I've seen plenty about using a battery charger when flashing but I haven't found any specifics. What amperage would be ideal? I'll be using a Schumacher XC75 which has 75 amp start/20-10 amp rapid charge/3 amp slow charge. I would assume I would use the rapid charge setting during a flash and wouldn't have to be concerned with overcharging a new or fully charged battery (this charger has circuit to protect anyhow) or introducing noise into the electrical system?

[Chris@Rvengeperformance]

With the big flashes like completely new versions I would have it on the 10 amp charge just to be safe. With the short flashes I just fire the car up and let it idle for 2 minutes or so, then shut it off and flash. I've also flashed plenty of times without doing either of those things, but of course I wouldn't recommend it.

[Greg E]

Both possibilities seem miniscule. Gregs file being corrupt would be less so. I've flashed my ecu's many times and without a charger and on a low battery. Luckily I haven't bricked anything yet, but that is why I have a test ecu that I always preflash my rom to. Just in case something somewhere goes wrong.

I would suggest everyone who flashes gets a battery charger to ensure a proper flash. Not worth having to go back and fix a brick.

The thing to take out of this discussion is that you can't trust any old ECU to flash peoperly. You should just buy a clone from Brett or Adam as any hardware issues will be fixed/warranted.

TDLR;

Friday buys junk yard board
Friday flashes junk yard board with battery tender and ECU still bricks
Friday opens the chrome XML to verify the correct processor type and accidentally deletes a character.
ECUFlash can no long read the chrome file
Friday sends ECU to Brett and Brett finds to board to be corroded
Friday buys new clone from Brett
Charger sends Friday new XML which enables ECUFlash to read chrome again
Flash of the same .bin file goes perfectly and Friday is happy.
Greg stands no chance at hooking up with Lady Gaga.

[Greg E]

With the big flashes like completely new versions I would have it on the 10 amp charge just to be safe. With the short flashes I just fire the car up and let it idle for 2 minutes or so, then shut it off and flash.

Quoted for Truth!

[ChargerX3]

Friday buys junk yard board
Friday flashes junk yard board with battery tender and ECU still bricks
Friday opens the chrome XML to verify the correct processor type and accidentally deletes a character.
ECUFlash can no long read the chrome file
Friday sends ECU to Brett and Brett finds to board to be corroded
Friday buys new clone from Brett
Charger sends Friday new XML which enables ECUFlash to read chrome again
Flash of the same .bin file goes perfectly and Friday is happy.
Greg buys a six pack...of Doritos Tacos.
Adam and Brett grasp hands and frolic through the woods...
Fixed!

[Chris@Rvengeperformance]

damn now I want some tacos

[fridayda13th]

So I've seen plenty about using a battery charger when flashing but I haven't found any specifics. What amperage would be ideal? I'll be using a Schumacher XC75 which has 75 amp start/20-10 amp rapid charge/3 amp slow charge. I would assume I would use the rapid charge setting during a flash and wouldn't have to be concerned with overcharging a new or fully charged battery (this charger has circuit to protect anyhow) or introducing noise into the electrical system?

I had one of those Schumacher from wal mart I tested the volt on it and i got 0 on all settings, I took it back to wal mart and got my 60 something buck back.