Flashhack - New LT1 flash tool

[steveo]

0.5.0 beta, highly recommended. please test it

http://fbodytech.com/flashhack/

[NomakeWan]

Corvette compatibility is completely broken again. Won't talk to either car. Sometimes it won't seem to do anything, other times it'll make the digital dash freak out and display "SYS" and flash the SECURITY light but nothing else. Log of attempting to talk to my '95 is attached.

Haven't tried swapping PCMs to test the checksum thing with 0.4.3, will do that tomorrow if the weather isn't terrible. It rained today so I didn't want to go yanking the PCM out of the car in the driveway.

[steveo]

i haven't really changed anything between the last version and this one that should affect how things connect. please do experiment with the timing settings to see if any adjustments help.

[NomakeWan]

Not sure what to tell you. No matter how many times I hit Read Calibration on either car, the same thing happens--it'll either time out nearly instantly and fail, or it'll send those burst messages like in the log and then complain about failing to become the bus master and fail.

I then switched back to 0.4.3 and it read without any issue on my '95 again. Then as soon as the PCM rebooted I swapped back to 0.5.0 and tried to read and it failed. So something changed between the two that the Corvettes don't like.

[steveo]

please do experiment with the timing settings to see if any adjustments help.

[steveo]

try burst length 6, timeout 10000, silence success 250, purge time 60
maybe the purge time being too high is making it wait too long between bursts

[sherlock9c1]

Flash hack 0.5.0 passes bench test on my B-body bin with no change in settings. No errors.

[steveo]

good to know at least b-bodies still work.

what i'd like to see is people playing with the timing on 'vettes since that's where the main trouble is, i really do think adjustment to those settings will yeild something that works, then make sure bbodies and fbodies work with those settings. i actually find the settings i posted above are quite a bit faster when i run a b-body bin. it should be safe to monkey around with those settings as long as you do not lower the "silence success" too low.

the whole reason for me exposing all those settings is so people with actual vehicles can figure it out

i obviously can't reproduce the problem on my test bench and reading logs all day wont tell me what the solution is

[NomakeWan]

try burst length 6, timeout 10000, silence success 250, purge time 60
maybe the purge time being too high is making it wait too long between bursts

These settings allowed 0.4.3 to connect instantly and successfully download the BIN without checksum errors on my '94--didn't even swap PCMs. However 0.5.0 still does not connect whatsoever; just makes the digital dash freak out.

[steveo]

well i can't explain why it would matter, but does this one work? the connection code is 100% identical to 0.4.3 and with the new timing settings locked in.

http://fbodytech.com/flashhack/

[NomakeWan]

well i can't explain why it would matter, but does this one work? the connection code is 100% identical to 0.4.3 and with the new timing settings locked in.

http://fbodytech.com/flashhack/

Worked perfectly! Connected first try, uploaded the routines (fans ran longer than previous flash programs--I assume this is due to uploading the larger routines to RAM?), downloaded both sides without errors. Great stuff!

[steveo]

so it works on both cars now?

guess we have our settings.

can you try with 16ms latency rather than 1ms for fun?

[NomakeWan]

so it works on both cars now?

guess we have our settings.

can you try with 16ms latency rather than 1ms for fun?

Upping the latency to 16ms caused all sorts of awful things to happen. It took three attempts to connect, and when it finally did connect and run it failed right at the end with a bad checksum error. I dropped it back to 1ms and reran the process. The first attempt after rerunning, the process failed at kernel upload. Then the second attempt failed to connect, then the third attempt connected just fine, identified what state the PCM was in, reset it and reloaded the kernels, and successfully read the BIN. That it is gracefully recovering and now successfully reads once it is fully connected convinces me that this is a solid program--assuming your serial adapter supports 1ms latency, anyway.

It works perfectly on my '95 without glitches, the above are just because the '94 has that weird noisy bus. I have a logic analyzer from Saleae on order, I'll see if I can't figure out what's going on using that once it arrives.

Anyway, now that we mostly have the comms stuff sorted (unless there are some improvements somewhere to make noisy stuff even more robust, but honestly it seems pretty darn good now), on to just housekeeping. First, it would be great if Flashhack could remember the selected COM port between runs. Even better if it could look at the available COM ports and select the most plausible one automatically (my laptop has a broadband wireless chip that exposes two COM ports; neither look anything like the FTDI adapter's virtual COM port, for example they don't expose their serial latency). There's a minor typo in the explanation for "Only write side(s) that have changed" and "Do not write 0xFF regions;" "recommended" has two Cs. In "Clear auto trans tables..." there is a reference to the setting "Patch unused regions," but this isn't the name of any option which can be confusing to an end-user. "Write T-SIDE" should have the same description as "Write E-SIDE" for consistency's sake.

Also, how does comparison writing work, currently? In EEHack it was obvious; you load the BIN you want to flash, you load the BIN that's already on the PCM (or use EEHack to read it), and then do the write. In Flashhack, "Load Bin" seems to be for loading the BIN you intend to write, so is performing a successful read sequence before writing the only way to do partial writes? For safety's sake that makes sense, but it would still be nice to have a way to manually specify a comparison BIN.

That's all I could think of from playing with the beta so far.

[steveo]

First, it would be great if Flashhack could remember the selected COM port between runs. Even better if it could look at the available COM ports and select the most plausible one automatically (my laptop has a broadband wireless chip that exposes two COM ports; neither look anything like the FTDI adapter's virtual COM port, for example they don't expose their serial latency).

it does that. if that port is missing or if no port was ever selected, it then auto-selects the first FTDI interface. it should not autoselect a non-ftdi interface. is it not working?

Also, how does comparison writing work, currently? In EEHack it was obvious; you load the BIN you want to flash, you load the BIN that's already on the PCM (or use EEHack to read it), and then do the write. In Flashhack, "Load Bin" seems to be for loading the BIN you intend to write, so is performing a successful read sequence before writing the only way to do partial writes? For safety's sake that makes sense, but it would still be nice to have a way to manually specify a comparison BIN.

it's more idiot proof than that. every time you successfully read or write an eeprom and that has been verified, it stores the bin itself. when you go to write a new bin, it compares with the last known successful bin.

it then runs a checksum algorithm on the ECM to verify the bin on the ECM hasn't changed (or we're not working on a different ECM entirely).

i guess i could make this per-vehicle but 99.9% of my users have one LT1, having the odd extra eeprom flashed isn't the end of the world, especially since this thing is pretty fast.

i've tested this pretty thorougly, although it's possible to doctor a bin so that checksum will think it's the same, since its not a complex hash or anything, in real-world tuning, that's unlikely.

thanks for the typos, i'll fix them eventually

[NomakeWan]

Hm, I thought I caught it trying to talk to one of my other COM ports during one of my tests, so I got into the habit of manually selecting on every start. I'll run some more tests later today to see if it's actually choosing the correct port on startup.

As for the check, that is great for the folks you're talking about who are hobbyists in a garage with a single LT1, but for those of us with multiple (or folks who might want to help work on other cars), it would be nice to have an advanced feature where we could specify a BIN like in EEHack. Or like you mentioned, have Flashhack able to store multiple BINs based on the VIN, so that it can keep track of any VIN it has previously interacted with. That would be super great.

I'm at work for a few more hours but once I'm off I'll test out that port selection stuff again. Cheers!