Flashhack - New LT1 flash tool

[NomakeWan]

im pretty sure it's 100% but if people report problems i can increase the delay further. i want you to test the multiple vehicle thing too.

0.6.2 is still listed as the current version on your site. As soon as 0.6.3 is there, I'd be happy to test both. ;)

[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

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

[steveo]

right on
close is okay
like i said before if you run into a collision just change your cal id to something random

[Greezmonkey]

how big is the file?
lets see the log

Here's what I saved

[steveo]

that bin is fine, 100% valid
edit: do you think it's factory stock? that calibration ID is a foreign export bin that we do not have. if you're pretty sure it's never been messed with i'd like to add it to my archive.

[NomakeWan]

Was gonna say, looked at it myself and it looks perfectly fine. Are you sure you're using the correct XDF for $EE? Either use steveo's EEX tuning definition (it's in his signature), or use EExtra from http://www.gearhead-efi.com/Fuel-Inj...E-xdf-(EEXTRA)

steveo's is the best for just loading and going. EEXTRA includes a ton of random stuff that is probably unnecessary unless you are doing crazy hacking of functions 99% of people don't use.

[NomakeWan]

Had a chance to flash a new BIN to my '95 today after a bit of a drive at work. Flashhack correctly identified that I had already flashed it, identified the parts of the BIN that were unnecessary, and ran a partial flash successfully. Total time from start of procedure to successful flash: 57 seconds.

Great work!!

[steveo]

nice that's good
i changed vin numbers on my test bench ecm a bunch of times and all my tests seemed successful but it's good to know it works in real life

[JimCT_9C1]

Tested reading and writing full and partial bins using b0.6.3 on 95 F and B body - all successful with no issues. Full write, selective write to each side, and read bin. Checked out fingerprinting with modified cal id and/or vin on multiple pcms. Flashhack kept track of it all.

I did come across a hiccup only on F-body - I could not reconnect to the bus after a change to the vin or cal id. Needed to cycle ignition power to be able to reconnect. This also would happen after load/unload kernel and closing the interface. I would get a heartbeat timeout message and a report that the bus was still noisy. This would not happen after reading or writing the bin itself, but only after completing one of these three operations.

Flashhack is a great tool - glad to help out on the above however I can.

Jim

[steveo]

can't imagine why that would only happen on the fbody, i guess a comms log of when that happens might be good? i've tested it on the bench and no problemo

[JimCT_9C1]

I could not reconnect to the bus after a change to the vin or cal id. Needed to cycle ignition power to be able to reconnect. This also would happen after load/unload kernel and closing the interface. I would get a heartbeat timeout message and a report that the bus was still noisy. This would not happen after reading or writing the bin itself, but only after completing one of these three operations.

Here are some comm log excerpts from F body - I also included connection traffic using 'debug idle traffic'.

I did some more tests to help isolate when this error does and does not occur. I found that for the kernel load/unload/close-interface case the error follows the use of the 'Close Interface' command. If I just load/unload and go to another operation it works without error.

This behavior with cal/vin/kernel-close is consistent and repeatable. Might there be a subtle difference between how these routines return control of the bus as compared to the bin read/write operations? Or how the PCM then re establishes communications with other modules?

F vs B body (9C1) might be due to differences in modules or timing. I have seen the same error on my 9C1 when I tried to connect too soon after key on and modules were apparently still chatting. Also, the 9C1 is kind of a bare bones B-body (no VATS, HVAC).

Hope this helps,

Jim

[steveo]

that's weird for sure. what's the latency set to for your FTDI interface? it's not finding the F056 message. i cannot reproduce the problem. i can only imagine the RX buffer is full of garbage for some reason,

can you do a test where after setting the vin you restart flashhack entirely?