New PCM, is it dead?

[ProfessWRX]

These issues have gotten exponentially worse. I didn't have constant fails before.

2 Failed reads in car almost immediately.

I did think of 2 other variables.

1. Bad USB cord
2. Bad USB port

I tried the second read with the COM4 USB port and it responded the same.

[ProfessWRX]

So out of curiosity, I just pulled my Tahoe bin with everything being the same.
Same cord, OBDX, USB port, same Beta PCMhammer.

Pulled with zero issues. I would have pulled it a second time but I didn't want to kill the battery.

What's to be made of this?

[MudDuck514]

Just checking, but he car in question has an L67 Supercharged 3800 V6?
Not the LATER L32 version?

Mike

[ProfessWRX]

Just checking, but he car in question has an L67 Supercharged 3800 V6?
Not the LATER L32 version?

Mike

L67

[Gampy]

Connectors, how tight are they ??

I have seen many sloppy loose connectors to the point they have to be positioned exactly right to even work, had to pull them apart and tighten them up.

-Enjoy

[ProfessWRX]

Connectors, how tight are they ??

I have seen many sloppy loose connectors to the point they have to be positioned exactly right to even work, had to pull them apart and tighten them up.

-Enjoy

They are very tight. I had considered that. I was incredibly still when trying to prevent any motion in the cord or anything else.
I even did the opposite when reading the Tahoe. I purposely moved a bit to see if that caused a disconnect. It didn’t.

[antus]

Are you saying the retries the same on the bench and in the car? Sometimes the data bus and other devices on it cause problems, but if the results are the same in car and on bench then it takes that out the question. OBD cable not coiled up?

[Tazzi]

These issues have gotten exponentially worse. I didn't have constant fails before.

2 Failed reads in car almost immediately.

I did think of 2 other variables.

1. Bad USB cord
2. Bad USB port

I tried the second read with the COM4 USB port and it responded the same.

So we have a couple things here:

1) P04 ECUs are a heap of shit in terms of how there DLC (VPW) is handled internally. Not only does the OS affect how stable the comms are (Even when running a kernel), but they do not apply a strong load on the bus line which can result in them dropping frames if the bus line is not loaded significantly during read/write at 4x speed. Pete and I discovered this after monitoring the VPW pulses, and adding a resistor between VPW line to ground (2.7-4.6k was ideal) to help the DLC clean up its signal.
This issue did affect when using GM MDI when performing a flash update, where the DLC dropped to 1x mode when it detected too many errors on the line (Which also affected the OBDX VT in the same manner), keep this comment in mind. The GM MDI also logged this, and continued flashing at 1x since its internal DLC dropped to 1x also.

2) Looking at your reads, it uploaded the kernel perfectly, and then read a bunch of chunks in a row without any dropouts. Then suddenly completely loss all communication here:

Code: Select all

[05:27:51:538]  Reading from 49152 / 0xC000, length 4096 / 0x1000
[05:27:51:554]  XPro: 20 01 00 DE
[05:27:51:565]  TX: 6D 10 F0 35 01 10 00 00 C0 00
[05:27:52:576]  Timeout.. no data present A
[05:27:52:585]  No payload following read request.
[05:27:53:594]  Timeout.. no data present A
[05:27:53:603]  No payload following read request.
[05:27:54:613]  Timeout.. no data present A
[05:27:54:622]  No payload following read request.
[05:27:55:632]  Timeout.. no data present A
[05:27:55:641]  No payload following read request.
[05:27:56:651]  Timeout.. no data present A
[05:27:56:659]  No payload following read request.
[05:27:56:668]  Unable to read segment: Error
[05:27:56:679]  XPro: 20 01 00 DE
[05:27:56:690]  TX: 6D 10 F0 35 01 10 00 00 C0 00

It then repeats sending the request several times without a single response back. This indicates to me that either the DLC has dropped back to 1x mode, or the kernel has dropped out.
Personally, I believe the DLC has dropped back to 1x mode which is why all communication has completely ceased.

This could be confirmed if PCMHammer dropped back to 1x mode, then sent the same command again and looked for a response.
Currently PCMHammer sends a mode20 while in 4x mode.. then drops back to 1x mode... and sends another mode20. So the code would need to be modified to test out.

The reason for the ECU DLC dropping to 1x can be due to:
- bad signal to ecu (Any jitter in the line can be identified as a fault at the DLC)
- other modules communicating at 1x (Waking up when told not to)
- lack of tester present fast enough

The alternative here is the kernel dropping out, but... I don't think thats the problem until testing the above theory.

The OBDX Pro tools used a heavier pull down in later revisions (Like the OBDX Pro VX.. which is the VTs supersession) to deal with bastard modules like the P04. The P04 actually works outside of the SAE spec technically, its slope for pulling back to ground from a high is actually way off, hence applying load (resistor to ground) clears up its signal significantly

[ProfessWRX]

Are you saying the retries the same on the bench and in the car? Sometimes the data bus and other devices on it cause problems, but if the results are the same in car and on bench then it takes that out the question. OBD cable not coiled up?

The results are different in bench and in car. Both have response delays.

In Bench, the comms are delyaed but eventually come through and the read ends up being successful, but with multiple Comms issues.

In car, is seems something resets when comms are delayed. The Dash comes back to normal and the comms never are allowed to return ending in a fail.

[ProfessWRX]

1) P04 ECUs are a heap of shit in terms of how there DLC (VPW) is handled internally. Not only does the OS affect how stable the comms are (Even when running a kernel), but they do not apply a strong load on the bus line which can result in them dropping frames if the bus line is not loaded significantly during read/write at 4x speed. Pete and I discovered this after monitoring the VPW pulses, and adding a resistor between VPW line to ground (2.7-4.6k was ideal) to help the DLC clean up its signal.
This issue did affect when using GM MDI when performing a flash update, where the DLC dropped to 1x mode when it detected too many errors on the line (Which also affected the OBDX VT in the same manner), keep this comment in mind. The GM MDI also logged this, and continued flashing at 1x since its internal DLC dropped to 1x also.

If this is the issue, then shouldn't I splice in a resistor into my bench harness and check?

2) Looking at your reads, it uploaded the kernel perfectly, and then read a bunch of chunks in a row without any dropouts. Then suddenly completely loss all communication here:

Code: Select all

[05:27:51:538]  Reading from 49152 / 0xC000, length 4096 / 0x1000
[05:27:51:554]  XPro: 20 01 00 DE
[05:27:51:565]  TX: 6D 10 F0 35 01 10 00 00 C0 00
[05:27:52:576]  Timeout.. no data present A
[05:27:52:585]  No payload following read request.
[05:27:53:594]  Timeout.. no data present A
[05:27:53:603]  No payload following read request.
[05:27:54:613]  Timeout.. no data present A

It then repeats sending the request several times without a single response back. This indicates to me that either the DLC has dropped back to 1x mode, or the kernel has dropped out.
Personally, I believe the DLC has dropped back to 1x mode which is why all communication has completely ceased.

Is this is the case, would the Dash not remain the same? When this happens the dash resets.

The alternative here is the kernel dropping out, but... I don't think thats the problem until testing the above theory.

With the behavior I see this makes sense to me, but I'm a lowly tester, not a dev.