$EEHack Read Failure Every Time?

[NomakeWan]

Update: Local electronics store said they had two FTDI Friends, but in fact they had zero (or they had been misplaced by people so badly that they will never again be found). They did however have the OSEPP version, which other forums are using as ALDL interfaces, so I picked that up. Tossed it on and it ended up exactly as flaky as the adapter I already have, leaving the ALDLcable as the most reliable of the bunch in terms of connectivity. If every single one I threw at it worked exactly the same way that would immediately make me think something was wrong with the car, either electrically in general or specific to the ALDL port's wiring...but the fact that one cable seems to work properly (except for Read in EEHack) and the others don't makes me wonder.

Reading is fine, I've got the BIN. My worry is that I'll start the flash procedure and whatever is causing this sort of behavior will rear its ugly head and brick it. Yet as far as I can tell the issue must be...

1. There is an electrical problem with the car that somehow the ALDLcable is working around better than the FTDI breakout boards.
2. There is a problem with the ROM on the car that doesn't prevent the car from running but does prevent EEHack from working correctly.
3. There is a problem with the latest FTDI driver for the RS232R (2.12.28), which is the driver being used for all of these.
4. There is a problem with my netbook's USB port.
5. There is a problem with EEHack.

I have a second netbook that runs XP, so I will give that a shot just for kicks in a bit.

EDIT: XP netbook worked the exact same way, so at least it's not an issue with my specific netbook or a quirk with Windows 7 x86's serial communications or something.

[steveo]

thing is if the read always succeeds in eehack but the checksum is always wrong, could be a problem with the bin itself. have you confirmed you're running EE and not EEB?

[NomakeWan]

When I open the BIN I downloaded with WinFlash in TunerPro using the EE definitions--any of the standard EE ones, whether that's the one from TunerPro, EEX, or EEXtra--the Injector Flow Rate and Cylinder Volume values are correct. If I use the EEB definition, they go crazy. So it does appear to be an EE ROM, unless somehow WinFlash is converting it by itself somehow.

[spfautsch]

I hate to ask stupid questions, but just to confirm... you do have y-body selected in eehack settings, and 'silence extra modules' is checked right?

Another tidbit that caught my eye earlier but forgot about is this:

except for toggling the SES light on and off, but I have a feeling that's related to it coming on whenever I plug anything into the 8192 data line

This seems odd to me. Are you saying the MIL illuminates whenever you physically connect to the port?

[NomakeWan]

I hate to ask stupid questions, but just to confirm... you do have y-body selected in eehack settings, and 'silence extra modules' is checked right?

Another tidbit that caught my eye earlier but forgot about is this:



This seems odd to me. Are you saying the MIL illuminates whenever you physically connect to the port?

Y-Body is selected and "silence extra modules" is on by default. That being said the program seems to ignore some things in the settings menu (like the 'do not warn' checkboxes, the 'save invalid bin' checkbox, and the COM port setting), so while I can confirm those selections are set, I cannot confirm the program is abiding by those selections.

The MIL thing I discovered was just because the car was not started. You can drive around with the ALDL cable plugged in and it won't trip the light, I just did it yesterday. My mistake. I'll have to try connecting while the car is running to see if I can flip the light.

[spfautsch]

Y-Body is selected and "silence extra modules" is on by default.

Just making sure. If your 'service abs' and 'service asr' lights come on when you connect that part is working as expected.

Yes, engine not running = MIL illuminated :-)

I'm still curious about the HPP3 flash and whether they tried to implement some sort of protection mechanism in the bin.

[kur4o]

The easiest way to check if the checksum are altered is to compare the bin, if the OS part have some corrections it might be the issue. They might have changed the start-end points of checksum calculation.

Still interested to see the bin in its corrupted state. Can you just save it ignoring the checksum message.

As a last resort try reading the pcm on a bench. If there is some ground issue or noise there, it can cause that kind of behaviour.

[spfautsch]

thing is if the read always succeeds in eehack but the checksum is always wrong, could be a problem with the bin itself.

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.

[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

[NomakeWan]

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.

[NomakeWan]

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...

[steveo]

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