Flashhack - New LT1 flash tool

[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!

[steveo]

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 not really into adding that complexity and choice and extra ui stuff to something that works fine in most cases and in the worst case just takes longer to flash, but if you wanted to try to write it, it's open source and i'll consider adding it to the main branch once its tested.

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.

it goes by com port number, of course, so if you had a device assigned to a comp port and later a different device is assigned the same com port number, it'll use that port without question. this is unavoidable, otherwise there would be no way for people to use non-ftdi interfaces.

but if your port is no longer valid, it shouldn't be auto-selecting a non ftdi port.

it's possible there's a bug somewhere, so let me know what you figure what's happening, but if it's just using a com port you selected due to moving interfaces around there's not much i can do about that. i think the detail log specifies when it's auto-selected an interface because yours was unavailable.