Flashhack - New LT1 flash tool

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.

Quote:

---

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/

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

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.

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

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?

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.

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?

i'm going to take a different approach to bus connection and lets see how that works but i'd like to know why yours fails on the bench and mine doesn't

is it because it's a b-body bin and the idle traffic it sends out is quite different, or is it because my serial interface works differently than yours?

can you run eehack's 'idle traffic scan' (in the debug section) on your bench setup?

That's what i get for trying to flash WAY past my bedtime. Gibberish and noisy bus traffic, hah.

Yeah I'll give it a whirl. This looks like a B-body BIN all right. I wonder what would happen if you put a B-body BIN on your setup. I think this has been discussed on here somewhere but how much BIN data outside of the XDF is unique to B, D, F, and Y?

really they're the same

one thing that's a difference is the comms code default bus master and module communications. the fbody and bbody bins use the ECM as bus master, and the ybody bins use the CCM as the bus master.

they didnt change much else, the f-body datastream even spits out the y-body and b-body specific stuff, it's just not 'in the definition file'

the fact that you did have issues and were able to re-flash again is definitely really good news, eehack would have bricked that thing for sure.

you are totally right that i should just flash a bbody bin but i suspect your interface might be sketchy

Quick update, in chronological order:
1. flashhack refuses to read (although it read this PCM once last night).
2. eehack reads just fine.
3. flashhack writes just fine.

I'll take further debug back-and-forth offline so I don't blow up this thread. Steveo, you have email.

every log you sent me is full of errors and problems becoming the bus master so the read/write tests arent really relevant

if it works at all its a fluke

until it connects without errors nothing will work properly

definitely an idle traffic log from eehack would be cool

its in the raw command window i think

i'm starting to think precise timing is the wrong approach. eehack had trouble here too. tunerpro is just awful at it. some interfaces have okay baud rates but their actual latency is awful. the current method works 100% on my particular laptop with my particular serial interface but that doesn't mean much. i have a drastic plan that will probably work. i will spend time on this and then need people to test it out...

As always, more than willing to do anything I can go help. Looking forward to the new experiment!

Hello i am new the tuning world and have downloaded tunerpro rt, eehaack, and your new flashhack. I have a 95 lt1 and 4l60e with a 8051 PCM from I believe a 95 roadmaster and will be installing in a 49 chevy coupe as standalone system. Just looking to do the basic things at first to get it running VATS delete being the biggest. I have no problem testing things out for you either. Just waiting for my aldl cable to arrive. Any tips for a beginner? Ooops forgot running Windows 10 if makes a difference.