Flashhack - New LT1 flash tool

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

[steveo]

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?

[sherlock9c1]

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?