$EEHack Read Failure Every Time?

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

He attached a zip of bins read with winflash in post #1.

[NomakeWan]

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.

The "save invalid bin" checkbox has no effect in EEHack, unfortunately. I do have bins read using WinFlash attached in the first post of this thread. TunerPro states the only changes between my BIN and the stock one I downloaded are Memory addresses, rev limit, cooling fan activation temperatures, knock limits, and of course VIN information as well as a few values specific to the Hypertech Power Programmer. I don't know if it checks program space but I assume it does?