Page 4 of 5 FirstFirst 12345 LastLast
Results 46 to 60 of 63

Thread: $EEHack Read Failure Every Time?

  1. #46
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Quote Originally Posted by NomakeWan View Post
    Actually kinda neat though, the ABS/ASR unit can tell you how many lateral Gs your car is pushing!
    Interesting. I have to wonder how accurate the 90's era solid state accellerometers are.

    Quote Originally Posted by NomakeWan View Post
    EDIT: Having a look at the service manual for the 1994 and 1995 Corvette, the HVAC is indeed tied into Pin 9 on the ALDL connector with everything else, which jives with it blinking when I try to connect anything to the line and shut everyone up. ... Odd that I can't find a reference to Y-body C68 HVAC in the Data Stream definitions.
    This is just a WAG, but I'd think the C68 climate control box might be a bus listener only and probably does not have the capability to transmit.

  2. #47
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    I work with 90s era hall-effect pendulum accelerometers actually! They’re...decent, if they’ve survived to the present day without their swing arms bending or their capacitors spewing their contents into the PCB. A little slow to react due to their mechanical nature but considering the speed of the computer interpreting them it’s not much of a bottleneck. That said, switching it to a modern MEMS version can improve performance depending on how the data is used. I haven’t tested ASR on the C4 yet but on a Skyline GT-R switching to MEMS has a noticeable improvement in AWD performance.

  3. #48
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    I doubt you'll find much reward in updating the ASR system to MEMS accelerometers. It seems the prevailing wisdom on this generation of traction control is that it works most effectively when disabled.

    Speaking from personal experience the only thing I appreciate about the system is the "haptic" feedback you feel on the pedal when the disconnect servo intervenes. But I've also experienced the joy of forgetting to disable it and having the ABS module lock up the rear tires at 30mph vehicle speed and 50mph tire speed. About as enjoyable as severe turbulence at 30,000 ft.

  4. #49
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Okay, so now that my Corvettes are finally back in my possession (and my garage), I've had a chance to do what I've been meaning to do for a while--run a serial port sniffer while operating both CATS WinFlash and EEHack. I've attached logs of what commands were sent over the serial data line to this post. As of this moment due to unfamiliarity with the program I haven't found a way to save a nice readable RX-and-TX log like EEHack does in verbose mode, but it's really the commands we're interested in, no? With EEHack it's a little trickier to compare since you can't run read/write without being connected first, so there's some unrelated datalogging stuff at the start before I can click over to read the ROM. With the WinFlash log it starts right when I hit "read." Note however that for some reason my sniffer missed the first two bits when reading from WinFlash, so I added them back in manually.

    Of interesting note, though I haven't been able to figure out why, is that my serial port sniffer has no problem running alongside EEHack and generates a small session file when I save the session (~1 MB). When I'm sniffing and run WinFlash, the session quickly explodes with data. By the end of a WinFlash Read session I've saved 90MB somehow. The raw binary data in text format is only 466 KB, so I have no clue how ~1MB of binary text explodes to 90MB. Considering the program is recording more data than just the raw binary TX/RX (such as session information, port status, etc) there may be something else WinFlash is doing that isn't visible in the actual data. Perhaps it's messing with the serial port itself somehow?

    I'll have to install TunerCats and see if it exhibits the same behavior while being sniffed. In the mean time, I hope that these can be helpful.

    EDIT: Here's a photo I took while logging. You can see some of the data streaming, but in the bottom of the photo you can also see where it says that it's logged over 70MB of data somehow.

    IMG_5344.jpg
    Attached Files Attached Files
    Last edited by NomakeWan; 10-05-2019 at 06:39 AM.

  5. #50
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    serial sniffing on something with tx and rx on the same line is difficult.

    the datalogger itself has to deal with the same thing, but since its sending the message, it knows to discard it when it's echoed back...

    but your serial sniffer being external sees the same data on the rx and tx lines so there's absolutely no way to differentiate between rx and tx without dissecting the messages themselves.

    to figure out what's being written and read you need to pay attention to the normal message format, and check the message length bytes to see how long it is, etc.

    trying to find the 'noise' in that log which is screwing up your aldl is going to be very difficult (if that's still what you're working on)

    i don't think there's anything special winflash is doing that'd generate a real 90mb+ file, something odd is going on there with the logger for sure.

  6. #51
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Just did an experiment with my manual car, the one that seems to have far less issues with connectivity. Sure enough, while EEHack doesn't do anything particularly different, the output log from serial sniffing WinFlash while it reads the ROM is significantly smaller--62 MB. And again, doing the same thing on my automatic '94 results in a 400 MB log. The data itself--the hex--isn't significantly different, but the sniffer is capturing more information about the datastream than just those hex bits and logging it. This makes me think that the difference is in how WinFlash is using the serial protocol itself. I don't know enough about the deeper aspects of serial data handling so right now I can't say exactly what that difference is, but I'll try to look at the log outputs and see if there's anything that jumps out at me.

  7. #52
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Please do a read on the bad car with eehack, and post the verbose log. I need to see where it fails, Does it fail on the same place or fails on a fixed elapsed time, like between 20-30% . Now with the version of eehack you can save invalid bins if the read goes through but the checksums are not correct.

    Sniffing on the port can be used only for hacking bus communication, to see what messages are transmitted and reverse engineer it, For troubleshooting you have to sniff the bus with other logging device connected to the aldl bus.

    I suspect that winflash is obfuscating the serial line to impair bus sniffing. I always got pc crashing while trying to do it. What software are you using for sniffing. I tried eltima and there, you can turn off some aspects of the logging.

  8. #53
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    If winflash is obfuscating the serial line, why is the log output consistent? On the 'bad' car, completing a read operation is consistently ~400 MB of log. On the 'good' car, completing a read operation is consistently ~60 MB of log. I would understand if the output was all over the place, but this consistency tells me that there is a very real difference between how WinFlash is handling talking to the 'good' car versus the 'bad' car.

    I'll get you that verbose log when I'm home from work. As for the software I'm using, it's Serial Monitor by HHD Software (in trial mode). The user interface is absolute garbage (clicking "File->Save" doesn't save your data, only your session config, so you have to click tools->save to log; clicking 'stop' to stop recording deletes all data and drops you back to the main screen; pressing 'pause' when playing back a log doesn't actually pause so you have to select frame-by-frame playback in advance when opening the log in order for the data to not stream by itself, etc), but the capability to passively log everything happening to the port so far has topped every other program I've tried. I couldn't figure out how to get Eltima to passively listen, it kept wanting to open the port (which of course stopped EEhack and WinFlash from being able to use it).
    Last edited by NomakeWan; 10-15-2019 at 05:00 PM.

  9. #54
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Apologies for the double post, but I've got the requested data. There is no rhyme or reason to when the read fails--it will fail every time, but when it fails is random. This randomness most certainly points to there being excessive noise on the ALDL line, noise which for some reason WinFlash is able to compensate for, seemingly by aggressively abusing the serial comms.

    Attached are the logs from two reads. The first read has 'silence additional modules' disabled as it's not really necessary anyway, and had streaming disabled. I did snapshot two data points just to get the ignition voltage values before flashing. The flash failed very quickly. The second read has 'silence additional modules' enabled just for the heck of it and kept streaming disabled, this time with no snapshots. The read went longer but errored out the same way. I included the eehack log of the first read, and the verbose debug outputs of both.
    Attached Files Attached Files

  10. #55
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Triple post! I had a chance to analyze some of the log output from my serial sniffer and found that, indeed, how the programs handle the serial communication is completely different. I've attached a few logs to this post. One is the verbose log output from EEhack when trying to read the '94 and failing. One is the sniffer's output during the same situation. One is the sniffer's output when WinFlash reads the '94. And the last is the sniffer's output when WinFlash reads the '95.

    I have snipped the sniffer outputs to all start at the same serial command--the unlock command--and proceed through ten subsequent serial requests, which includes uploading the read routines and requesting some of the initial data.

    What you can see first off is that EEhack starts at the end of the memory address space and works backwards. WinFlash starts at the beginning of the memory address space and works forwards. Not that that's terribly important, but it is a difference. WinFlash also has waaaaaaay more bus commands than EEhack does per write command. It has less when talking to cleaner signal--like on the 95--and more when the signal is dirty--like on the 94.

    Hopefully this helps somehow. Let me know if there's anything else I can do to help.
    Attached Files Attached Files

  11. #56
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I see some errors while reading e-side only. Doing some more verbose failed attemps can reveal some patterns.

    I didn`t notice but did you try to read the 95 pcm in the 94 car. It is really odd problem and I am trying to rule out the obvious.

  12. #57
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Yes I did try to read the 95 PCM in the 94 car and it failed the same way. Likewise the 94 PCM in the 95 worked fine. It's clearly something to do with the car.

    I'll do as many verbose failed attempts as ya like. Once my laptop's recharged I'll go out and do a couple in a row and save the logs and attach them here. Gimme an hour or two.

    EDIT: Logs are attached. Shockingly the second attempt I made actually succeeded for the first time ever and let me save the BIN! But trying again and again after that resulted in the usual read failures.
    Attached Files Attached Files
    Last edited by NomakeWan; 10-18-2019 at 06:39 AM.

  13. #58
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Posts added to above thread.

    Indeed, it always seems to give up on the E-side; all three of these logged failures happened when it requested a specific bit of data, got incorrectly-checksum'd responses three times in a row, and gave up at that point. However, if you look further through the logs you can see that the same situation happens on the T-side as well, albeit never seeming to hit EEHack's three-strikes read failure limit. So I honestly believe it's coincidence that the E-side is where it eventually fails. I think if I were to do 100 read attempts, it would probably end up with more than its fair share of T-side failures too, looking at the logs.

    In any case, please do check out the serial sniffer outputs. The way WinFlash handles the serial data buffers is wildly different from how EEhack handles serial comms. I believe it's worth investigating. :)

  14. #59
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I see right before the error occurs there are some random bytes changed in the message like 00 changed to 02 or 08 and the checksum byte is the same, so it it is really a checksum failure due to incorrectly received message.

    Now the reason these bytes change from 00 to something else is not clear. Some momentary noise or some kind of ground issue.
    If you can go through tunercats log and find if there are some errors in the packets there and does TC retries some of the packets, It will be pure checksum errors handling difference. I bet will be unsafe to flash even with TC.

    To log with eltima you need to connect first with the tuner program. When the port is opened by the tuner program, open new session, select the serial port used by the tuner program, mark the checkboxes and press OK.

    It should start monitor the port. Don`t try to open any ports with eltima, just start new session. It will give you better perspective if the same packet is requested over again.

  15. #60
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    I have successfully flashed using WinFlash on the ‘94 at least 20 times now, with 100% success rate. I wouldn’t dare try flashing with EEhack, which is too bad because I would love that datalogging speed bonus patch that I can’t seem to find in any XDFs. I can flash with EEHack on the ‘95 though.

    I’ll go ahead and look through the logs for WinFlash and see if I can find checksum repeats. It’s a lot harder to find than checking the verbose EEHack debug, but the concept should be similar, so I’ll see if I can figure out some way to count repeats in commands. That should give me all the points in the log where a request is repeated.

    But again, please do pay attention to the serial comm buffer activity. EEHack seems to demand precise timing, rejecting short or long packets and trying over if the timing was off. WinFlash appears to wait until the size of the buffer contents is the size it expects before pulling the buffer contents, independent of timing. This action seems to be far more resilient of minor timing issues, and the amount of “waiting” is actually where that massive difference in log size between the ‘94 and ‘95 comes from. Watch the buffer query messages pile up on the ‘94 between requests versus the same requests on the ‘95! ;)

Similar Threads

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

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
  •