Flashhack - New LT1 flash tool

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

[steveo]

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

[sherlock9c1]

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.

[steveo]

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