1994 Corvette EEHack DataLog Review

[kur4o]

I have done hundreds of reads and never had an issue. Could it be a vette specific bug. Interesting how pcm gets unlocked for a flash but fails to unlock for a read. A log will help. Maybe some unexpected response, gets picked. You might try removing battery on next fail to read, just to be sure.

I just remeber there are some timers with mode 13. Before it expires the pcm can`t be unlocked. It might be a good idea to wait some time after ignition is on, before starting a read. There are also different responses if an error occurs.

The best dyi boards have that designhttps://www.ebay.com/itm/FT232RL-3-3...UAAOSwxDxcnsjk.

I have tried other with mixed results.

[spfautsch]

kur4o-

I highly doubt it's a Y body specific bug, but would you elaborate a bit on the timers you speak of?

It's highly possible some amount of key on time would help - it takes far less time to initiate a read sequence because there's no bin to select, and no "are you sure" warning nag to answer as there is with flashing. I've flashed hundreds of times without a single issue, and it only seems to cause me difficulty when I'm in a hurry (or in this case testing a read).

[steveo]

the only difference between getting ready for read or write is we don't upload the code to set VPP voltage for read (since it's not necessary), i can't imagine that has any effect

[spfautsch]

It has worked for me, I have a file named 'vette-eehack-read-0521.bin' in my 2016 logs and bins folder. I had no other reason to do a read other than to test eehack's read function.

If there's some timer that needs to expire in the ecu it may be possible to wait a few seconds after launching the flash window before enabling any of those functions so the key seed issue doesn't happen to others.

[kur4o]

The timer is set at pcm reset and until it expires, the pcm can`t access mode 13. It is also reloaded at some point, maybe to prevent mode 13 at engine running.

I suspect it to be 8-10 seconds timout after reset is done, before you can access security mode. Rearmed on wrong key.

There are some other timers too. One of it is the time between seed response and key recieved. The purpose of the others is not so clear.

[steveo]

kur4o could we get around that? dump the timer ram to see if its active and wait if it is? whats its location?

[spfautsch]

Thanks kur4o - that was it. Seemed to be about 10s from key on. Three reads in a row, no problems. As I mentioned steveo if we disabled all the buttons on the flash window for 10s after initialization that would take care of it. Or even easier just make the error message more descriptive along the lines of waiting longer. Had I known about the timers, well I can follow directions. Those who cannot will ask questions regardless.

RISK81 -

I feel confident your issue will be resolved with a diy cable.

[RISK81]

Thanks kur4o - that was it. Seemed to be about 10s from key on. Three reads in a row, no problems. As I mentioned steveo if we disabled all the buttons on the flash window for 10s after initialization that would take care of it. Or even easier just make the error message more descriptive along the lines of waiting longer. Had I known about the timers, well I can follow directions. Those who cannot will ask questions regardless.

RISK81 -

I feel confident your issue will be resolved with a diy cable.

Guys, Thanks for investigating the READ issue. As of now I have placed an order for the Adafruit IC bridge USB-UART Module (PN_1528-2591-ND) and also the Adafruit FTDI Serial TTL-232 USB Cable (PN_1528-1644-ND) through Digi-Key. Once the units are received, I'll construct a basic temporary cable and terminate to the mentioned pins listed above and post the results regarding the read function after a 10 sec delay from key-on.

If this checks-out I like the idea of terminating a permanent cable to the back-side of the ALDL connector at the specified pins with appropriate strain-relief for future flashing / data-logging.

Thanks again for everyone looking into this matter.