pcmhacking.net

Typically error should break, timeout should continue.

However it is of my opinion that whole bit of code needs to be re-written utilizing Response<Message> proper if ReadDVIPacket(...) is properly returning a Response<Message>.
Any other code calling ReadDVIPacket(...) would need looking at as well ...

As for the Network message (line 342) Response<Message>, possibly, however at this point in time I do not know what else would be more appropriate then error strictly judging by the fact it was null previously.

P59 1mb ecu reflashed to 7603 os and custom bin
no issues with wright

[03:25:06:942] Calculating CRCs from file...
[03:25:06:973] Requesting CRCs from PCM...
[03:25:07:020] Range File CRC PCM CRC Verdict Purpose
[03:25:08:096] 0F0000-0FFFFF 8D0F8F91 8D0F8F91 Same OperatingSystem
[03:25:09:157] 0E0000-0EFFFF A50F3C90 A50F3C90 Same OperatingSystem
[03:25:10:218] 0D0000-0DFFFF A50F3C90 A50F3C90 Same OperatingSystem
[03:25:11:279] 0C0000-0CFFFF A50F3C90 A50F3C90 Same OperatingSystem
[03:25:12:340] 0B0000-0BFFFF A50F3C90 A50F3C90 Same OperatingSystem
[03:25:13:400] 0A0000-0AFFFF A50F3C90 A50F3C90 Same OperatingSystem
[03:25:14:461] 090000-09FFFF 7DA5C19F 7DA5C19F Same OperatingSystem
[03:25:15:522] 080000-08FFFF CDDEAE4C CDDEAE4C Same OperatingSystem
[03:25:16:583] 070000-07FFFF D006BDC7 D006BDC7 Same OperatingSystem
[03:25:17:644] 060000-06FFFF D2B04EC0 D2B04EC0 Same OperatingSystem
[03:25:18:704] 050000-05FFFF 36511E94 36511E94 Same OperatingSystem
[03:25:19:765] 040000-04FFFF F6B0E81A F6B0E81A Same OperatingSystem
[03:25:20:842] 030000-03FFFF A97E3395 A97E3395 Same OperatingSystem
[03:25:21:902] 020000-02FFFF EE1B7BAD EE1B7BAD Same OperatingSystem
[03:25:22:963] 010000-01FFFF A5700F21 A5700F21 Same Calibration
[03:25:23:525] 008000-00FFFF 300CD29D 300CD29D Same Calibration
[03:25:23:540] 006000-007FFF not needed not needed n/a Parameter
[03:25:23:556] 004000-005FFF not needed not needed n/a Parameter
[03:25:23:868] 000000-003FFF AE42598F AE42598F Same Boot
[03:25:23:884] All relevant ranges are identical.
[03:25:23:915] All write-request messages succeeded on the first try. You have an excellent connection to the PCM.
[03:25:23:930] We're not sure how much retrying is normal for a write operation on a 1024kb PCM.
[03:25:23:946] Please help by sharing your results in the PCM Hammer thread at pcmhacking.net.
[03:25:23:977] Clearing trouble codes.
[03:25:25:054] Elapsed time 00:05:29.3477785

wilber1978,

Thank you for posting your write success ...

-Enjoy

Hello, I have been doing a little testing with Gampy with my OBDLink MX, which apparently isn't really supported by this, but figured I would mess around with it a bit since I already have it.

What's really strange about all of this and what's kept me interested in testing it is.... My first time ever trying PCM Hammer v14 I was able to read a P01 and P59 with zero issues or errors. I was doing a PCM swap and figured I would get a bin backup of each. Both reads were done on a totally functional and complete car (2003 Corvette Z06).

Fast forward a few weeks I was trying to do a read again on the P59 and it's just tons of errors. I can't think of any logical reason why or how it went from totally working to totally worthless.

Tried a few test writes, maybe 4 or so now. 2 had no errors, 1 had 2 retries and this last attempt required 1 retry.

Read and write logs attached for anyone who might be interested.

edit: the read log is a proper debug log, but I accidently only saved the normal log for the write. but you get the idea.

It has to be problems with your wiring harness or too low of a voltage to your PCM. The MX+ device with PCM Hammer and LS Droid has worked perfectly for me.

Rick

I don't think so, but who knows. Nothing has changed since it worked great those first 2 times. Also the pcm is licensed with Efi live and it has absolute zero issues. I read the MX has less memory than the MX+ and maybe LX too.

Open to any other ideas/thoughts or things I can try.

If you are doing this with the PCM installed in a vehicle, there will likely be other bus traffic to / from the Body Control Module that will interfere your reads and writes with the PCM. Absolutely everything I do here is with the PCM out of the vehicle and sitting on the kitchen table.

Rick

I'm inclined to blame other modules on the bus as well... But if you're having this trouble in the same vehicle that was having NO trouble earlier, then I dunno...

The single retry you got during the test write seems like no big deal. In the early days of XPro testing I had some successful writes with a couple dozen retries.

After the read attempt had that truncated packet, did you cancel the read yourself? I wonder what would happen if it was left to keep trying on its own.

Yeah, I think the only reason I am interested in this is because I did 2x successful reads with zero errors before.

When I did the P59 read, I can't remember if that was before or after I did the VATS relink, maybe that is a factor regarding the other traffic messing it up.

But either way, that doesn't explain how I got a perfect read on my original P01 before I pulled it.

I'll keep messing around and let you all know if I/we figure out anything.

Maybe a longshot, but going to try downgrading my MX firmware and see what happens. Read some stuff about LS droid recommending older firmware. I don't think I've updated it since the successful reads, but it's worth trying I suppose.

I did cancel the read after it reached about 1%.....if you look at the time stamps its' super super slow. IIRC I let it run about 5 minutes and then cancel.

Hi all im new here and just finished my first reflash on a 4896 pcm

Os changed to 12212156 2002 5.3l 4l60e 4x4 for a s10 blazer 4x4 swap

when it completed the flash it said to share the log here. hopefully this is the right section.