$EEHack Read Failure Every Time?

[NomakeWan]

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!

[spfautsch]

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 (http://www.gearhead-efi.com/Fuel-Injection/showthread.php?7981-Connection-issue-cable-will-not-work-with-eehack)<

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

[NomakeWan]

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.

[steveo]

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

[NomakeWan]

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!

[steveo]

do this too

http://fbodytech.com/ftdi-serial-latency-and-threaded-eehack/

[NomakeWan]

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 (https://www.microcenter.com/product/486570/ftdi-adapter-usb-controller) 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.

[steveo]

odd for sure. just use winflash to read the bin then. you only need to do it once

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

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

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

[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

[NomakeWan]

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!

[NomakeWan]

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.

[steveo]

just for the hell of it swap ecms and see if it behaves itself on your new (working but beat up) car

[NomakeWan]

Haven't had an opportunity to swap PCMs yet (I might get around to that tomorrow) but I did have a chance to drive the '94 for a bit on an errand to try to replicate an issue I experienced a few days ago where the car banged off the rev limiter rather than shifting into third. Couldn't replicate the issue (which further makes me think clutch packs, but we'll see how a fluid and filter change does for now), but did get some nice datalogs that show some of the weird data being experienced. Just as you had mentioned, the knock counts do go back down to sane levels after the glitch, but the data does appear in the graph and makes me curious as to whether the analyzer is taking these glitchy data frames into account.

14567

14568

I'll update again once I have a chance to swap PCMs.

[steveo]

i agree that the data is corrupt for that frame, BLM cell 50 isn't a real thing.

it's either corrupt data in ram from the ECM itself or corruption on the datastream wire. i'd suspect the second, as corruption in ECM ram would cause your car to stumble and die.

except for in insanely small mathematical cases, interference on the wire will cause the checksum to be invalid, that's the entire point of having one. when the checksum is invalid it should reject that data in eehack and discard. i mentioned earlier there are some potential bugs concerning checksums in eehack. i'll try to get you a new version to try shortly

your analysis results in the knock map will obviously be totally off but fueling corrections are probably still useable because we're averaging into cells, if you have 100 good records and 1 suspect one, you probably wont notice the bad one. that's why averaging is used for fuel analysis in the first place, but that's assuming your data set is large enough.

[kur4o]

I have noticed similar spikes in logs at random rate, and I was almost sure it was an error in spi communication between e and t side, due to some of the patches I had over that bus. Now that guy have similar problems which should also be related with the random dtcs popping for a single frame.

Corrupted ram is out of question, so it could be shorter than expected message or corrupted message being passed. Some closer look at the debug log and the logged data should reveal the cause.

[NomakeWan]

Just went out and swapped PCMs, and confirmed that when I put the '94's PCM into the '95, I get zero connection errors. I didn't start the car since I didn't know what would happen putting an automatic PCM into a manual, but I don't need to start the car to get errors randomly on the '94, so no big. So there does appear to be a problem inherent to the chassis somewhere, not inherent to the PCM. Time to tear into the ALDL harness as well as inspect all the grounds, perhaps this weekend.

Also, steveo, how does the "Transmission Perf Button Pressed" indicator work in EEHack? It shows up as "ON" constantly on mine unless I ground pin 13 on the grey connector, at which point it reads "OFF" until the ground is disconnected. From what I've read this switch is just a momentary switch with a ground connection, so perhaps it should be the other way around? Maybe it's different on an F-Body?

[steveo]

could you please try the latest beta out to see if you get any similar data corruption? i dont know anyone else getting that problem consistently enough to be a guinea pig

[NomakeWan]

Okay, tried the latest version and it works wildly differently from the old one. The error counts skyrocket (250 in 17 minutes, 500 in 34 minutes), but analyzing the resulting logs I no longer have any one-frame DTCs, BLMs over 18, insane knock events, or anything of the sort. It appears to be doing exactly what it's supposed to do--reject the bad data. :) I have attached the log of the drive to this post.

In addition, the read routine now fails every single time--but does so properly. With 4.7.0 the read routine would either successfully complete and then complain about a checksum issue or would fail partway in an unrecoverable fashion that required me to remove the ECM fuse behind the battery to get back to normal operation. I tried the read function four times with 4.8.0 and all four times it got about 25% through and then hit an unrecoverable error, the program reset the E-Side and T-Side, and dropped me back to a working state as it's supposed to do. I've attached a verbose debug log of one such read attempt for reference. This still proves that there's an underlying serial data issue on my '94, but at least now EEHack is handling these errors with grace. :)

I did notice some other bugs, but I'll go ahead and post them in the EEHack 2019 thread instead.

[steveo]

awesome thanks for that testing. you've confirmed it was definitely ignoring checksums in the last version. honestly given the drastic changes in the datastream code over the last few versions, and given then fact that I did it without a test bench or a car to try it on, i'm not surprised. glad it's fixed.

you definitely have a noisy aldl bus in that car but I wonder if it's a device that decides to keep chattering (corvettes definitely have a noisy aldl bus) i'd be curious to see if you ever find out what's up with that... if it's just a device we need to shut up, we can do that easily...

[NomakeWan]

Since I have the RPO sheets for both cars, I can say that in terms of features the only difference between the two cars electronically is that the '94 has the FX3 suspension and the 4L60E transmission. The transmission is handled by the PCM so that's not likely (right?), and the FX3 IIRC has its own communication that is separate from ALDL and has no ability to transmit serial data. Not to mention the problem existed before I knew that the FX3 module on my car had been unplugged, so I'm going to guess that's a red herring.

Both cars have passive keyless entry, automatic climate control, Bose audio, dual airbags, ABS, ASR, cruise control. The '95 has a bad alternator (it whines like a supercharger) but that doesn't seem to affect the data. The '94 has bad data even when the engine isn't running anyway.

I did go out and do testing on the grounds. Both vehicles use the OBDII-style 16-pin ALDL connector. On both vehicles, Pin 4 reads 92 ohms between pin 4 on the ALDL and the negative post of the battery. On both vehicles, Pin 5 reads a fluctuating value between 130 and 212 ohms between pin 5 of the ALDL and the negative post of the battery. This would seem to indicate to me that ground on the ALDL connector is not the issue. It could still very well be the 8192 signal wire.

On the '95, the previous owner was under the driver's side dash to replace a brake booster. He left the footwell light unplugged but otherwise it seems to all be there. On the '94 there is no real evidence that someone has been under there, but I did notice that the ALDL connectors on each car are mounted differently. On the '94 it's mounted pointing straight down, with one bolt and one plastic lug. On the '95 it's mounted on a bracket that points it towards the firewall and is held on with two bolts. I can't be sure if this was a year-to-year difference or a clue as I only have these two cars to work with.

[NomakeWan]

I apologize for the double post. I decided to try out TunerPro RT for the first time. EE_Auto.adx didn't work at all. $EE-16188051-Y-body-V3.8.adx worked perfectly...or so it seemed. It connects without issue and shows 0 errors straight through. But when you go back and look at the data, you still get a few random frames of absolute junk that the program accepted as legitimate data rather than as errors. For example, ignition voltage 19.7, engine run time 60427, knock count 18437...etc. It's clear that this is bad data, but just like EEHack used to, TunerPro RT is accepting bad frames as good for some reason.

I also tried Scan9495 v2.6.2 and it didn't want to stay connected either. It does have a verbose log generator too, so I went ahead and nabbed that. It's attached to this post. If the problem is with something on the ALDL line that won't shut up, surely there would be a way for me to listen for it and find it, right?

[steveo]

since its writing over a running datastream its hard to tell which device is misbehaving but maybe we can probe a bit. ill see what i can come up with

[steveo]

we had a conversation qutie a while ago perhaps involving kur4o where we talked about some b-body and y-body extra devices, but the only one that we deemed necessary to 'maybe' silence was the brake controller. i think at that time we had a list of potential devices on the lt1 aldl bus... can anyone help find that thread?

[kur4o]

That 94-95scan program is not configured for y-bodies at all. It tries to silence the f4 device, which is the pcm. On y-body the bus master is the CCM device with f1 id.

I think the aldl is configured with 1 bus master device that can request data from other devices. All slave devices are passive and only response to request from the bus master, when needed.

Every 1-2 seconds the bus master sends it`s ID with a broadcast ID message F0 56 [ID]
ID can be f4 or e4 pcm, f1 CCM, f9 some newer stuff.

It will be much easier for eehack to identify the bus master and than sends the shut up command to that ID.

On f-bodies and some b-bodies the traction control part of the brake module communicates with the pcm to request traction spark retard, On y-bodies it is an analog setup.

I still think it is some grounding issues or sensor noise with this particular car. Start disabling things like alternator, dashboard, pulling fuses and so on.

You can open the raw window in eehack and do some idle scan log.


Here are some random idle scan logs.

[kur4o]

doublepost

[NomakeWan]

Found the idle chatter logger thing and took some logs. Filenames are what state the car was in when the log was taken. Please let me know if there's any other test I can perform, I'll be more than happy to do whatever test is necessary to pin down this issue. :)

[kur4o]

Nothing unusual in the logs. It seems that only the ccm is talking and other modules are passive listeners, only the pcm response to the requests of the CCM. I am not sure if the CCM should talk with ignition off.
You can try disconnect the CCM fuses and repeat the logs. Than try to read the PCM, with CCM off and make a verbose log.

[spfautsch]

I can tell you from experience the CCM starts talking when you open a door. I've been using a FTDI board hanging on the passenger's side of the console with rx/tx leds on it for several years, and when mine's not connected to my usb hub the leds start flashing away when I open the passenger side door.

The PKE coming into range most likely causes chatter on the aldl - mine doesn't work correctly so I have no idea.

[steveo]

there must be command sets for the ccm has anyone seen any documentation for them? a .ds file or something?

[NomakeWan]

Here's the DS file for the 1994 Corvette CCM: http://gearhead-efi.com/gearhead-efi/def/aldl/A239.DS

I'm currently mid-project on a drivetrain swap for a GTR which is on jackstands in my driveway, so my Corvette is in the driveway under a car cover. I won't be able to play around with it until this Sunday at the earliest. Might take until the weekend after, we'll see.

[steveo]

well i don't see much good there to help with our comms but why dont we add that to the definition for the next version.... i did write multiple device support into EEHack, and it's barely been tested. there is some cool stuff in there. i wonder if it responds to any of the other commands we usually use for reflash, read ram, etc?

[NomakeWan]

Good question! I have some serial data apps on my laptop so I can try talking manually once I'm able to mess with the car again. I've done it just fine on Subarus and Nissans, not sure how well it'll work on a GM but I'll give it a whirl once I can.

If we're adding definitions, here's a list of what filenames refer to what:
http://www.totalcardiagnostics.com/pages/gm-datastream-definitions.htm

And here's the database of the actual GM data stream definitions once you know what's what:
http://gearhead-efi.com/gearhead-efi/def/aldl/

For the '94-'95 Corvette, though, these are what I've found:

A175 ABS/ASR 1992-1994 CORVETTE
A223 1994-1995 CORVETTE AUTOMATIC TRANSMISSION
A239 1994 CORVETTE CCM
A242 1994-1995 SIR/SRS
A275 1994-1995 CORVETTE MANUAL TRANSMISSION
A288 ABS/ASR 1995 CORVETTE
A297 1995 CORVETTE CCM

Unfortunately I couldn't locate a definition for the HVAC system for the Y-body, or the passive keyless entry system. Actually kinda neat though, the ABS/ASR unit can tell you how many lateral Gs your car is pushing!

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. PKE however is on a totally different pin, same with FX3. Odd that I can't find a reference to Y-body C68 HVAC in the Data Stream definitions.

[spfautsch]

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.


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.

[NomakeWan]

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.

[spfautsch]

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.

[NomakeWan]

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.

14699

[steveo]

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.

[NomakeWan]

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.

[kur4o]

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.

[NomakeWan]

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

[NomakeWan]

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.

[NomakeWan]

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.

[kur4o]

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.

[NomakeWan]

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.

[NomakeWan]

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

[kur4o]

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.

[NomakeWan]

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! ;)

[steveo]

your analysis of how eehack recieves data is totally incorrect with regards to timing. it doesn't demand anything but correct data. it receives all available data with at least a 1 second per request timeout until the packet length that is expected is recieved. of course a packet that's the wrong length is definitely in error so it's rejected immediately, and it does retry the last request in most cases, which is the only logic that will work to continue operating, as the ECM doesn't have any knowledge that the request has failed.

it also has things like dynamic garbage collection in place which stops sending packets for a short time after a major error and discards any out-of-band bytes which is a great way to reject noise which is a momentary issue and maintain a good datalogging rate, this is something i tested by causing deliberate serial interference and it's necessary to not nuke a datastream as the serial interface will happily buffer the noise and the datalogger will eat it right up. every valid packet will decrease the time spent collecting leftover serial noise between packets, every erroneous packet increases it.

the analysis you're doing could yield interesting things but you should stop looking for a software solution to your problem which is 100% in hardware somewhere (i base this on the fact that nobody else having this problem....).

most of the eehack users that say 'hey eehack doesnt flash my car but winflash does' end up having winflash brick their car later. maybe it's nice my software is a bit more bitchy and gives up more easily when there's so much noise on the bus. think of it as a feature not a bug

[steveo]

also waiting around until the buffer is 'more full' has nothing to do with noise rejection. reading one big buffer full of noise or lots of short buffers of noise will give you identical results.

[NomakeWan]

Fair enough. I went looking for differences based on bus communication, led by the repeatable, consistent results of tests via a serial comm sniffer. I will be the first person to say that I have no firm grasp on the underpinnings of serial communication, as my knowledge only goes as far as picking the protocol rules (baud, 8N1, etc) and sending hex bits and getting hex bits in return. So I was going through the logged data with only 'pattern recognition' rather than an actual understanding of what was happening.

I do agree, based on the verbose output, that random bits appear to be being flipped for no reason. And that, as discussed before, there is something inherent to this particular chassis that is causing that to happen. Both things most certainly point to the ALDL bus being noisy or otherwise unreliable in terms of level state. Sadly I don't yet have an oscilliscope to do waveform analysis, but I suppose starting over and inspecting every ground on the car starting with removing the battery and inspecting the PCM wiring more thoroughly is in order.

I finally have quality Corvette time this weekend thanks to our race car stuff being finished, so I intend to get a bunch done. I'll report back if anything changes. :) Thank you once more, steveo, for making a fantastic program. I know it seems like I must be bashing it but seriously, I'm not--I just wish I could use it as much on my '94 as I already do on my '95, because it really is that good.