Another thought - he said it has a canned flash on it from a HPP3 standalone programmer. Could this have altered the checksum algo? I'm completely ignorant as to how that works, so just spitballing here.Originally Posted by steveo
Another thought - he said it has a canned flash on it from a HPP3 standalone programmer. Could this have altered the checksum algo? I'm completely ignorant as to how that works, so just spitballing here.
i didn't read that part. its totally possible that the bin is just borked then. that bin sucks anyway, you should just flash back to factory and go from there. yes hypertech does odd things with checksums
Just flashed a new BIN to the car using WinFlash. The BIN was just the GM EE_16200891 with the VIN changed to my VIN and the BLM locker enabled. Flash succeeded, car runs just fine (though it looks like it reset my passive entry system, so I'll need to reprogram that), but EEHack still fails to read in the exact same way. The read process completes successfully but then says there's a checksum error and doesn't save any data.
Just as an update, I went ahead and read back the ROM using WinFlash to see if it would match what I wrote to the car. Excluding the RAM addresses (which are of course different, but irrelevantly so), the only differences between the BIN I wrote and the one I read back was "Siderail Serial Number" and an "Unknown" value, which considering my experience lead me to believe are in fact values for the passive security system. As soon as I can get my hands on another remote I will be able to test that theory.
Point is, what I wrote and what I read matched. I then tried to do a read using $EEHack with RAM Dump enabled, to see if maybe excluding RAM from the read was part of the problem. Nope--it took an additional 30 seconds to read, but still declared a checksum error and saved no data. I'm totally stumped.
Is there any sort of test version of the program with logging specific to this problem enabled I can use to help get to the bottom of this? I'd love to help in any way I can so I can dump CATS and stick to $EEHack, it's a much better program in my opinion...
appreciate you putting all this effort into trying to get it working
i have no idea why read would repeatedly fail in your case
i didn't spend much time working on or debugging flash read or building debugging features for it because to be honest nobody uses it, all the stock LT1 bins have already been read and are posted online
i'd love to help you debug it further but i don't have a ton of time on my hands right now
i plan to get another version of eehack out the door by the end of summer, i'll try to at least get the bug fixed that prevents a bin from being saved even if the checksum is incorrect, i never tested it since none of my read attempts ever had bad checksums
also don't really recommend using flash write in eehack till you figure out what's up
Yeah, that's exactly why I want to help out however I can. EEHack is a way better all-around program, so I'd love to use it on its own--but if it can't read I assumed it wasn't safe to write either. That's why I've been using WinFlash.
I can completely understand being low on time. I've got plenty of other stuff I can try to fix on the car, but I'll be around to help with anything you need should the time arise.
Best of luck!
Update!
I recently acquired a manual '95 and of course immediately plugged into it. EEHack works with zero communication errors. Reading the BIN works perfectly as well, and I assume flashing does as well (though I haven't tried it yet).
I'm not sure if this helps any to try to pin down where the problem lies. The car is in far rougher shape than my '94, so I'm not sure "maintenance" is the difference here. The automatic transmission? Something specific to the '94 with the OBDII-style 16-pin connector?
Figured I'd put it out there.
Posting Permissions
Reply With Quote
Bookmarks