Flashhack - New LT1 flash tool

[steveo]

this is a continuation of a previous thread: http://www.gearhead-efi.com/Fuel-Inj...-EEHack-update

Made a new flash tool that surpasses the one built into EEHack, it's currently in beta and needs testing by people who don't actually rely on their LT1 to go to work in case something goes wrong, but i'm pretty confident it wont.

Flashhack is a completely free-as-in-beer next-generation tool for flashing older GM ECMs that allows you to read and write your calibration data quickly and safely with common affordable hardware. Right now it only reflashes $EE (8051) LT1 ECMs but it’s built with other ECMs in mind.

This is intended to replace and surpass EEHack’s built-in flash tool, which worked and had a reasonably low failure rate, but was a total nightmare of cobbled together spaghetti code and handled some failure conditions badly.

Flashhack’s main goal is maximum stability and speed, and seamless error recovery, making it very unlikely that you could permanently brick an ECM due to a malfunction.

It uses persistent kernels and logic to ensure that if your ECM still has ignition power, you can try to flash again until it succeeds, even with a different computer and ALDL interface. If the ECM itself loses power, there is only a small window of approx. 7 seconds (between the erase cycle and the first few write blocks) where an ECM power failure may cause the ECM to become unusable. If a power failure occurs during 98%+ of your write operation, you should be able to start over.

Unlike other flash tools, clicking buttons or doing other things like browsing the web while the flash is in progress should not brick your ECM. The worst case should be restarting the program and writing again.

download current version and get more info here:

http://fbodytech.com/flashhack/

[steveo]

If you are having trouble connecting reduce your serial interface latency like this:

http://fbodytech.com/wp-content/uplo...di_latency.png

Short term to-do list / bugs in case anyone wants to help:

- Implement EEHack's patches in EEX as eehack's flash tool will probably go away, so we should be able to apply them in TunerPRO instead, maybe that's what I should have done in the first place.

- Find out why we still have connection trouble with Y-Bodies (maybe B-Bodies too??)

- Test failure conditions more thoroughly (hopefully people with socketed ECMs or lots of balls). I personally can't make it brick my test bench ECM anymore unless I pull ECM power halfway through the erase program, but sometimes restarting the program itself may be required.

- Test with other types of serial interfaces

[sherlock9c1]

Steve, sent you an email. I tried an OBD1 PCM hooked up into a '96 B-body with a new (to me) adapter hooked to pins 9 and 5 but couldn't make it work. So I pulled the PCM out and hooked it to my old benchtop programming harness connected to a new car battery and on a charger. Both eehack and flashhack read it just fine. BTW I think eehack isn't letting go of the COM port because I was getting access denied errors when trying to use flashhack after eehack even though I'd closed eehack. But anyway...

I tried using flashhack to write, and it burped about halfway through the T side and is continuing to give errors when trying to write to the T side. I left power on to the PCM but cycled the ignition several times and it read just fine several times afterward, so at least that's good. But it's got OxFF's in most of the T side still. I emailed you a log.

[steveo]

thanks for all the testing. i'll read through those logs but i'm having trouble finding the point where the write failed.

i notice that you're having connection issues, which is weird on a test bench for sure, do you have a different serial interface you can try just for fun?

we can flash it back to normal i'm sure

it wont write either side if you're trying to flash an identical bin to one that was previously written or read successfully but it'd be nice to have more details on what's going on there. just turn the 'only write sides that have changed' parameter off if you don't want that

[steveo]

i looked a little bit more, both bins you've sent me that say 'after bad write' actually look intact.

the tside isn't full of 0xFFs, the eside is, though, which is normal if you choose 'set unused regions to 0xff' and 'do not write 0xff regions' (eehack does the same thing)

either way your tside is totally intact, are you sure about the failure?

generally when the write fails and the retry limit was reached, an error message exists like this:

We've given up trying to write the TSIDE

i searched your log for the words 'given up' and couldn't find. can you point out where it failed?

[sherlock9c1]

I may have not saved the actual log of where it hosed on the T side in the first place.

EDIT - just read your post. Huh. Maybe it's fine. This is a new-to-me PCM that looks like it was out of a '95 B-body. I went to run a diff in TunerPro last night to see whether the FF's were showing up in a region that didn't matter, but ran out of brainpower.

Also, which logs do you want me to send? Debug? COMMS? add the timestamp?

EDIT - I really need to get a car together so I can drive it and test everything!

EDIT 2 - what's with all the 'noisy comm bus' warnings? And it only seems to occur during one operation, not sprinkled throughout activity.

[steveo]

the comms logs with timestamps is perfect!

and typing notes about your observations in there is great too.

the noisy comms messages are during initial connection which is obviously having some grief.

first it tests to see if the bus is quiet.

if it's not, it listens to determine the current bus master

then it tries to silence the bus master.

it listens again to see if it's quiet

and repeat..

edit: right at the beginning of your log you flash C:/Program Files (x86)/EEHack/BINs/floridabin1_From_flashhack.bin
and the operation is successful (and checksum verified)
i don't see a failed write after that

so it failed before? do you remember what kind of errors came up?

[Greezmonkey]

Steve, I have down loaded the new flashhack and tried to get my original bin loaded from the 94-Buick Roadmaster system I'm using. I've read it several times but when trying to save it the file it won't save as a .bin file. I've uploaded the saved files just to check the data into Tuner Pro but nothing was in the file. The "save as type" doesn't offer a bin type.
Want to save original before using an existing bin for the updates I need to make.

[steveo]

I've uploaded the saved files just to check the data into Tuner Pro but nothing was in the file.

i don't understand what that means. do you mean the file is empty? have you pressed 'read calibration'? can you post the log of that?

The "save as type" doesn't offer a bin type.

yeah it does and has for a few versions now. you might not be using the latest version

[Greezmonkey]

You were right. I had version 5.9 loaded. I just loaded your 6.2 Clicked “read calibration”. Was a successful read and asked to save with a file name. This version does offer the .bin file. I saved it and loaded it into Tuner Pro to see the data. Looked at the “Spark Advance vs RPM vs Map” in the tables, the table had no data in it. When I loaded one of your bins from your site of Factory LT1 bins the same table is full of values.
In scalars the "vehicle speed limit" is 183 in your bin and 0 in mine.

[steveo]

how big is the file?
lets see the log

[Greezmonkey]

how big is the file?
lets see the log

Here's what I saved

[steveo]

new version is up
reset thing should work
just use load/unload kernel to test while viewing comms log

[NomakeWan]

Tested it out and it had zero issues reading either car this time. No reboot problems. The unique signature is significantly shorter in this version, and the first two digits of both my cars match, but the remainder is unique to each. I don't have any changes to commit to either vehicle just yet, but as soon as I do I'll see if it detects the signature and maintains the same signature after flashing.