Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 1 of 5 12345 LastLast
Results 1 to 15 of 63

Thread: $EEHack Read Failure Every Time?

  1. #1
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    90

    Exclamation $EEHack Read Failure Every Time?

    Hello,

    So I've been testing out EEHack with a cable from ALDLcable on my '94 with the 16-pin connector. The program itself seems to work just fine--I can clearly see correct data, and the actuators all do exactly what they're supposed to (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). However, whenever I try to read the stock ROM from my car, the read fails at the end with a checksum error. I've tried tens of times with the same result every time but one. The one time I had something different happen was when it failed partway through and warned me I needed to pull the PCM fuse. Once I figured which fuse that was everything was fine with the car. I did try CATS's WinFlash tool and that did successfully pull the ROM. I threw it into TunerPro with EEX and it loaded up fine. After switching the XDF to EEXTRA I discovered that someone had, at some point in this car's past, flashed the PCM with a Hypertech Power Programmer III. I don't know if that's related, but I figure I'll put as much info in here as possible with hopes that it'll lead to a fix. I noticed I'm not the only one with this issue, but the other threads across the internet don't have any solutions either.

    What I've tried:
    Checking battery voltage. Initially yes, it was low--11.7V on my DMM. I left the car on the charger all day and came home to it at 12.8V. Tried again three times but still got the same result. Notably the successful read with WinFlash was done before checking battery voltage.
    Checking cable settings. Initially the COM port was set to 16ms latency. I changed it to 1ms. That improved speeds marginally but didn't change the outcome at all.
    Changing USB ports. No change.
    Changing COM port. Did this because CATS's tool won't let you select any port number over 8. No change.
    Changed setting in $EEHack to allow saving invalid BINs. Didn't do anything at all. Similarly found that $EEhack doesn't remember my setting for COM port (it always goes back to 4), and ignores my setting for not warning me before closing without saving a log...basically the program doesn't seem to like paying attention to the settings menu at all.
    Changed program to "Run as Administrator." No changes.
    Uninstalled program from default directory, wiped registry key, reinstalled program to my own user directory to rule out access permissions issues. No changes.
    Tried out kur4o's latest beta fork. Same result, and similarly ignored everything in the settings menu too.

    What I've noticed:
    WinFlash has no problem connecting and reading the ROM to a BIN, but it seems to struggle to display vehicle information when the car is first turned on without first commanding a read. When it finally does work, all the information populates except for Calibration ID, which does not. $EEHack's main page displays all values including Calibration ID as soon as the connection is established, every time. I've done two reads with WinFlash, and using VBinDiff there are differences between the two, but they seem to be in specific locations. Loading the two BINs into TunerPro and using its difference tool, it reports that all of these differences are in MEMORY areas, which I assume are RAM, which is why they're different and thus not relevant. Hopefully this is a correct assumption.

    What I have not tried:
    Switching compatibility modes. I do not think this is necessary with a Qt program on Windows 7, even though it was absolutely necessary in order to get WinFlash to even install.
    Flashing the completely stock ROM. On the off chance there is something wrong in my setup or with one of the programs, I do not want to brick the car. I would rather ask for expert assistance first and be asked by said experts to do so after careful analysis of the problem at hand than go with the nuclear option right off the bat.

    The laptop I'm using is Windows 7 32-bit. I installed $EEhack natively, not using any compatibility modes, and don't have any compatibility modes set. I will attach to this post a screenshot of the outcome of a read with $EEHack, a verbose log output of starting $EEHack and only attempting a read (start car -> wait 10 seconds -> open $EEHack -> Connect -> wait 10 seconds -> Flash Read -> Exit), and the two dumps from WinFlash. Hopefully we can figure this out.

    Thank you!
    Attached Images Attached Images
    Attached Files Attached Files

  2. #2
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    486
    FYI, the aldlcables piece is a know problem w/ eehack. I think steveo managed to borrow one to try and troubleshoot but he's a busy guy.

    >link<

    My suggestion is to make your own with an ftdifriend or similar.

  3. #3
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    90
    Somehow I had missed that thread when I was searching through all the stuff on Google. I'm not sure how it slipped past me, so I apologize. I'll try cracking open the cable to see what chipset it is.

    Hilariously enough I was so impatient waiting for the cable to arrive that I DID build my own out of a 5V FTDI Friend, but the instructions I followed required a 1N914 diode and a 4.7k resistor on the TX and RX lines to prevent a potential current surge in the event of crosstalk. This cable worked (barely, not well) with Scan9495 and not even once with EEHack. I suppose I can try removing the protection circuitry and wiring it directly to the car instead and see if that works.

    Thank you for the reply! I look forward to updates.

  4. #4
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,728
    no diodes and resistors necessary

    eehack was mostly developed and tested with the rx and tx wires literally twisted together and hanging in mid air, from a cheap ftdi ebay board

  5. #5
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    90
    Well that settles that!! As soon as I get home from work I'll swap out the protection circuit wiring for bare wires and run another test!

  6. #6

  7. #7
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    90
    Sadly, no good news.

    I had already lowered latency to 1ms before posting this thread, so there's that. I did change the USB buffer size to 1024 as in your screenshot just for kicks but that didn't change anything either.

    So I tried my FTDI friend, or rather, THIS one from my local electronics store. It was flaky almost immediately. I only managed to complete a read once, after which it said the same "invalid checksum" error. All other attempts it would fail at some random point and force me to yank the ECM fuse to get everything back. I thought it might be bad connection between my test leads and the socket, so I desoldered the socket, soldered together the TX and RX pins, then soldered wires directly to the GND and TX/RX pins. This changed nothing, it was just as flaky as it always had been.

    FT_PROG reports that the chipset on both my flaky device and my perfectly-working-except-for-EEHack-Reads ALDLcable is the FT232R. Neither is FT232B. The cable seems to have zero issue talking to the car otherwise, it just won't let me read the ROM in EEHack. My little dongle though, nothing doing.

    I suppose I could drop by there and pick up the Adafruit version just to see if that would do anything different. If it doesn't I can always return it. I'll do that tomorrow after work. But for now, I figured I'd drop that update.

  8. #8

  9. #9
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    90
    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.
    Last edited by NomakeWan; 07-11-2019 at 03:25 PM.

  10. #10
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,728
    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?

  11. #11
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    90
    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.

  12. #12
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    486
    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:

    Quote Originally Posted by NomakeWan
    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?

  13. #13
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    486
    Quote Originally Posted by steveo View Post
    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.

  14. #14
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    90
    Quote Originally Posted by spfautsch View Post
    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.

  15. #15
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    486
    Quote Originally Posted by NomakeWan View Post
    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.

Similar Threads

  1. First Time Posting Long time as a fly on the wall
    By Mrgto68 in forum Introductions
    Replies: 0
    Last Post: 12-17-2018, 02:00 PM
  2. Long time listener, first time caller.
    By Shameless in forum Introductions
    Replies: 1
    Last Post: 06-25-2018, 08:26 PM
  3. EEHack continuous checksum failure ???
    By kris72079 in forum GM EFI Systems
    Replies: 17
    Last Post: 09-01-2017, 12:17 PM
  4. Would Checksum failure cause these issues?
    By trippyjoey in forum GM EFI Systems
    Replies: 8
    Last Post: 10-01-2014, 11:22 AM
  5. ERROR: PROM I/O returned failure?
    By brian617 in forum TunerPro Tuning Talk
    Replies: 4
    Last Post: 10-13-2013, 03:51 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •