Flashhack - New LT1 flash tool

[steveo]

i've always figured the chips were part of the extra crap that GM was doing related to obd-ii level emissions testing experiments on corvette owners (that's why they have a rear o2 and why all EE bins have a huge datastream message with obd-ii parameters in it) although i have no hard evidence of that and haven't pulled apart a 1333 ecm myself

one thing to realize when you're swapping 1333 for 8051 ecms back and forth and trying to flash them is that the 1333 does not act as a bus master (it expects a CCM) so if you throw it into an fbody there will be no bus master. flashhack should deal with that just fine. if you put an 8051 into a 'vette with a ccm then both the ecm and ccm will probably want to be bus master, and i'm not sure that would work out well, so it might be best to yank the fuse for the ccm until you've flashed a y-body bin on it

[spfautsch]

Interesting ideas steveo. I wonder if the smaller chips are related to the additional O2(s?). I guess I can confirm / disprove by looking for post-cat O2 voltage in the datastream.

Though it was likely salvaged from a B body based on the knock module PN, this 8051 came out of a Y body and already had Y VIN on it, although the last 6 digits were zeros. Cal id at 0x0e20 was 16209281. I think that's a Y body bin but correct me if I'm wrong - the PO had it tuned presumably by a mail-order place for a 377 displacement. Strange, I just noticed there's a different cal id at 0x2000 and 0x12000 - 16209647 and 16209648 respectively. These addresses are zeroed out in my original manual bin (cal id 16210071).

This makes me curious what the 28 pin IC might be. PN appears to be 185 16179922 which google doesn't turn up much on.

Edit: I found this interesting - Tom H's '97 F-body thread here shows this location populated with something else that he's referring to as the "data link controller". Also mentions there's a capacitor to ground and current limiting resistor. This is intriguing, because the first thing I started to wonder when I discovered the electrical differences is what if the ALDL circuitry in the 8051 is not impedance-matched to the Y body's ALDL. Just some wild speculation, but still intriguing.

If I get overly bored I'll try running it in the car. I don't think I tested any functionality other than starting and logging briefly. Can't find where I saved that log so I probably didn't.

[kur4o]

That is the vpw class 2 communication chip present on obd2 pcms. The smaller ones that are missing are the rear 02 drivers.

[NomakeWan]

Though it was likely salvaged from a B body based on the knock module PN, this 8051 came out of a Y body and already had Y VIN on it, although the last 6 digits were zeros. Cal id at 0x0e20 was 16209281. I think that's a Y body bin but correct me if I'm wrong - the PO had it tuned presumably by a mail-order place for a 377 displacement. Strange, I just noticed there's a different cal id at 0x2000 and 0x12000 - 16209647 and 16209648 respectively. These addresses are zeroed out in my original manual bin (cal id 16210071).

My stock '95 manual BIN has cal ID 16210071, 0x2000 16209648, 0x12000 16209647. I know for a fact it is stock and was never touched before I started fiddling with it.

My stock '94 auto BIN was touched by a Hypertech before I started fiddling with it, but has cal ID 16200891, 0x2000 16200875, 0x12000 16200874.

Having those zeroed out appears to be shenanigans.

one thing to realize when you're swapping 1333 for 8051 ecms back and forth and trying to flash them is that the 1333 does not act as a bus master (it expects a CCM) so if you throw it into an fbody there will be no bus master. flashhack should deal with that just fine. if you put an 8051 into a 'vette with a ccm then both the ecm and ccm will probably want to be bus master, and i'm not sure that would work out well, so it might be best to yank the fuse for the ccm until you've flashed a y-body bin on it

Interesting. This must be in one of the "Item not defined" sections of the XDF; I can't seem to find a reference in TunerPro to being the ALDL bus master. I mean sure, goes with the territory depending on which type of BIN you're flashing, but just kinda curious where exactly in the code this behavior is located.

[steveo]

99% of the code isn't defined in the xdf but it's possible there is a flag or something

[NomakeWan]

99% of the code isn't defined in the xdf but it's possible there is a flag or something

By 'the XDF' I meant EEXTRA v0[1].001[MOD_V0005_03_02]V6_3, which has the majority of the code defined. But even with all the nitty-gritty experimental stuff commented, there still doesn't appear to be anything related to being the serial bus master.

[kur4o]

By 'the XDF' I meant EEXTRA v0[1].001[MOD_V0005_03_02]V6_3, which has the majority of the code defined. But even with all the nitty-gritty experimental stuff commented, there still doesn't appear to be anything related to being the serial bus master.

Look at the 3AC7 mode7 offset address.

This is a scheduler table for 16 messages sent at idle mode. You put the address or pointer to the message in the code. When set to 0000 the pcm stays quite.

From f-body cal

F253
0000
0000
0000
F2B7
0000
0000
0000
F2CB
0000
0000
0000
F2B7
0000
0000
0000

One of these addresses is for the bus master message.
On vette bins all are set to 0000 so nothing is transmitted actively. The pcm respons to CCM requests only.

[steveo]

nice work! look at how busy a caddy bin is compared to an f-body. it would be useful on b-body standalone swaps to simply use the f-body message pointers so that communications are easier.

F2CB
0000
F2D7
0000
F2F5
0000
0000
F31B
0000
0000
F325
0000
F32F
0000
F339
0000

[NomakeWan]

Dang, that's awesome! Very useful stuff, thanks for that! I'll make a note of it in my XDF.

[spfautsch]

That's a really interesting find kur4o.

I wanted to get the ecu boards back in their cases and off my workbench today so I made some time for a little investigation.

I didn't trace things out exhaustively, but apparently the 1333 ecu having the class 2 serial chip in it is unrelated / unconnected to the obd-1 serial aldl. I've never once considered plugging in an obd-2 scan tool to see if it can talk but I might because pin 7 blue is apparently connected to pin 2 on the aldl connector.

Anyway, tracing the 8192 baud aldl to the 28 pin smt ic labeled 64606 / DELCO 466 to the left of the class 2 chip, I noted a vastly different resistor on the rear of the board that either ties to another pin on the 64606 chip or ground. Both boards had a 10 ohm in series with the trace for the 8192 baud bus and the 64606 chip, but the other resistor was labeled 75k ohm on the 1333 ecu, where the 8501 had a 910 ohm.

Also worth noting is that pin 29/30 blue measures 64k ohms to the ground plane on the 1333 ecu, while the 8051 measures 2.2k. In hindsight I probably could have measured this without opening the cases and satisfied my curiosity.

To me it seems the 1333 ecu is designed to present a vastly different impedance to the 8192 baud bus. Whether or not this has anything to do with the PCM being designated as a slave is anyone's guess. But it definitely explains why I see so many more comm errors with this ecu in the car. I doubt I'll ever bother running it in the car to test if the CCM / ABS / ASR have any issues with this, don't really care all that much. But I thought I'd share my observations before I put this stuff in a storage tote and delve into more diy-ltcc work.

[WASyL]

hi

i have downloaded P66 flash from 93 Fbody and most of the data is bullshit, tried different XDF (from here and PCMhacking) and no luck. in attachment "stock" bin i have downloaded from PCM, tried one of BIN found on here and also data is mixed or is there an issue with XDF's ?

best regards

[steveo]

what xdf are you using?

i don't know if i've seen a good XDF for that engine on here.

there are some tables in there for sure so i can only assume it's not just gibberish, but it's possible that you're the first one to try flashhack on that engine, and i don't think many people have tuned them so XDFs might be nonexistant or really shoddy.

one thing that sucks is that as far as i've been told the P66 bin itself doesn't really contain a factory checksum value to verify it's integrity.

i just realized while looking at that issue that i could easily accomplish a validation of a read procedure by utilizing the same manual checksum routine we use to validate writes. i will put code in the next version that validates the bin that way to help ensure read integrity and maybe someone with a P66 can help me test it.

each message is checksummed too, so the chances of corruption on read are low even without that extra validation

unfortunately this does mean flashhack or any other flash tool would probably still load a totally corrupt bin from your PC and flash it without complaint, but there's no reasonable way to fix that issue, so be careful with that

[steveo]

hey another question for you wasyl, did you check the 'read ram region' box in the advanced section? i thought i had that disabled by default but it looks like it read the whole bin anyway. just want to make sure there isn't a bug there.

[WASyL]

XDF was taken from here http://gearhead-efi.com/Fuel-Injecti...rmation-P66-V6

no i have not checked "read ram region"

[RayMGB]

what xdf are you using?

i don't know if i've seen a good XDF for that engine on here.

there are some tables in there for sure so i can only assume it's not just gibberish, but it's possible that you're the first one to try flashhack on that engine, and i don't think many people have tuned them so XDFs might be nonexistant or really shoddy.

one thing that sucks is that as far as i've been told the P66 bin itself doesn't really contain a factory checksum value to verify it's integrity.

i just realized while looking at that issue that i could easily accomplish a validation of a read procedure by utilizing the same manual checksum routine we use to validate writes. i will put code in the next version that validates the bin that way to help ensure read integrity and maybe someone with a P66 can help me test it.

each message is checksummed too, so the chances of corruption on read are low even without that extra validation

unfortunately this does mean flashhack or any other flash tool would probably still load a totally corrupt bin from your PC and flash it without complaint, but there's no reasonable way to fix that issue, so be careful with that

I have looked into trying to adjust a BIN using TP V5 for a 93 F body 3.4l and there does NOT appear to be a XDF available for the 93 Fbody 3.4l engines. The only XDF available (P66 V6) is for the 94/95 Fbody. If you use the 94/95 XDF on a 93 Fbody ECM half the data shown will be garbage. I wish there was an XDF for the 93 3.4l Fbody.