openecu.org

colby, any update on when you will have the sti and fxt rom downloading feature added to your program?

there is a guy local to me that has a ECUTek tuned 04 sti and he is thinking of getting a Cobb AP and just wiping out his ECU. i'd like to use my openport cable to download his current map before he does so.

This feature performs an actual reflash of the ECU. Do not use this until you are sure of what you are doing, and have had success with the "test" flashing. Obviously, any interruption of this reflashing process could render your ECU inoperative. As can flashing a corrupt flash image, or one intended for a different model ECU / car.

Once a flash is interrupted (say, by a laptop crashing) and the ECU is inoperative, could you re-run the flash program to correctly flash the ECU?

From my limited experience programming other chips through a serial interface, the programming portion of memory should still be intact (thought about this a bit more... intact unless that portion was loaded to RAM to let its flash memory space to be overwritten, doh). I'll have to read up to see if this is the case for the ECU. I'd just like to know that there's room for error if I'm using a finicky laptop.

The flash code is there until the ECU is reset. Just don't turn off the car...

bofh wrote:The flash code is there until the ECU is reset. Just don't turn off the car...

In that case, if my laptop crashes in the middle of a flash, I should just re-attempt the flash, leaving the ignition on? The OpenECU software should still be able to communicate with the ECU for flashing purposes?

PossumK wrote:

bofh wrote:The flash code is there until the ECU is reset. Just don't turn off the car...

In that case, if my laptop crashes in the middle of a flash, I should just re-attempt the flash, leaving the ignition on? The OpenECU software should still be able to communicate with the ECU for flashing purposes?

This is what has been said. However, I have not had the urge to "test" it myself.

I believe as long as the com port is not closed you should be able to continue communicating with the ECU. If the laptop crashes, you might be screwed.

I would try to find a reliable laptop before attempting this, unless you have a spare ECU handy.

Mike

This is true, as I know first hand. I have had quite a few flashes fail on me. Let me tell you, when you see that error, boy does your heart start pumping. Lol

"I would try to find a reliable laptop before attempting this, unless you have a spare ECU handy"

Good advice!! We have already seen one toasted ECU.

What does the manufacturer use to flash a corrupted or new ECU? Something that connects to the main header?

the manufacturer doesn't deal with corrupted end user ECUs, i'm sure the dealer just orders a new one. if it can't be reflashed and fixed with their equipment.

PossumK wrote:What does the manufacturer use to flash a corrupted or new ECU? Something that connects to the main header?

If the ECU is an HC16, you can use a BDM (or JTAG) to re-flash the device, as long as the CPU is functioning. They typically talk directly to the core of the micro, allowing you full access to ALL the flash memory, full read/write. Even if your flash is corrupted and the micro is not running a program.

They plug into a special connector on the PCB, assuming its put there by the manufacturer. Otherwise, you would have to wire one on.

I've done alot of HC11 programming as well lots of 16bit DSP programming DSP56F800. I actually own a HC12 BDM, but I haven't done anything with it. Not sure if it would work with the HC16.

PossumK wrote:

bofh wrote:The flash code is there until the ECU is reset. Just don't turn off the car...

In that case, if my laptop crashes in the middle of a flash, I should just re-attempt the flash, leaving the ignition on? The OpenECU software should still be able to communicate with the ECU for flashing purposes?

I am releasing a new version of ecuflash/kernel soon which has better recovery characteristics. Until then, what you want to keep in mind is this:

When your laptop crashes, the OpenECU kernel code is still running in your ECU and listening for your laptop. Because of the checksummed packet communications that the kernel uses, it will only execute complete, valid commands. This means that the kernel is likely alive and you should leave the car on and just re-attempt the flashing process on the laptop. My newer version of the kernel code also auto timeouts when you send it bad packets so that you don't have stream sync issues when the laptop comes back online. The Ecuflash program evaluates what areas need to be reflashed each time it runs, so it recovers from partial flashes without a problem.

What will kill your ECU is to turn your car off after having a partial or otherwise incorrect reflash. At this point the OpenECU kernel stops running, and the ECU CPU starts running the invalid code. The only way to recover the CPU at that point is with a hardware programmer.

"I am releasing a new version of ecuflash/kernel soon" I can't wait to see it!

I have a new version of EcuFlash posted at the top of this thread now, but it is only a small change from the current version to support the OpenPort 1.2. All of my work right now is going into a new multi-platform GUI version. From there I hope to add the map editing and other goodies.

Colby

Now your just teasing me


"OpenPort 1.2" - Whats the diffrence between 1.2 and 1.1?