First time trying to read the binary from the PCM. Gets to block 0x4000 and get an unable to read segment error. From looking through the code, it looks like it fails the checksum as I am getting 0x00 on bytes 10 and 11. The entire block is filled with mostly 0x00 and 0xFF. Everything else reads fine up until this point. I have attached the log of this happening.
I then decided to run a Verify Entire PCM against the file "12216125_1GNEC13Z32R141325" from Snoman002. Produced the below results. Looks like the OS and bootloader are the same which is a good sign. I was thinking I had an entire corrupt memory or something. Looks like it could just be corrupt in that block but I can't be sure.
Now my question is, is this something that has happened to anyone else and was there something to help fix it? Or should I just say screw it and flash in the 12216125_1GNEC13Z32R141325? I was maybe planning on rebuilding the program to ignore the checksum so that I can see if anything else is messed up.
[12:49:13:376] Validating 512k file.
[12:49:13:439] Start End Stored Needed Verdict Segment Name
[12:49:13:483] 00000 7FFFD A36B A36B Good Operating system
[12:49:13:550] 08002 15C4F 6065 6065 Good Engine calibration
[12:49:13:594] 15C52 193CF EDA4 EDA4 Good Engine diagnostics.
[12:49:13:641] 193D2 1D6EF E4A4 E4A4 Good Transmission calibration
[12:49:13:675] 1D6F2 1E02F B1C8 B1C8 Good Transmission diagnostics
[12:49:13:710] 1E032 1EE6F 41BE 41BE Good Fuel system
[12:49:13:749] 1EE72 1F3EF D30B D30B Good System
[12:49:13:783] 1F3F2 1F4EF 3368 3368 Good Speedometer
[12:49:13:818] Requesting operating system ID...
[12:49:13:975] PCM and file are both for the same Hardware P01_P59
[12:49:14:010] PCM and file are both operating system 12216125
[12:49:14:168] Unlock succeeded.
[12:49:14:232] This interface does not support VPW 4x
[12:49:15:101] Kernel upload 9% complete.
[12:49:16:108] Kernel upload 22% complete.
[12:49:17:148] Kernel upload 35% complete.
[12:49:18:209] Kernel upload 48% complete.
[12:49:19:303] Kernel upload 61% complete.
[12:49:20:653] Kernel upload 74% complete.
[12:49:21:795] Kernel upload 87% complete.
[12:49:23:204] Kernel upload 100% complete.
[12:49:24:582] Kernel Version: 01030501
[12:49:24:603] Kernel uploaded to PCM succesfully.
[12:49:25:023] PCM and image file are both operating system 12216125
[12:49:25:529] Flash chip: Intel 28F400B, 512kb
[12:49:25:734] Calculating CRCs from file.
[12:49:25:753] Initializing CRC algorithm on PCM, this will take a minute...
[12:49:38:340] Requesting CRCs from PCM.
[12:49:38:456] Range File CRC PCM CRC Verdict Purpose
[12:49:46:973] 060000-07FFFF D8C98FAF D8C98FAF Same OperatingSystem
[12:49:55:477] 040000-05FFFF 244EF6F9 244EF6F9 Same OperatingSystem
[12:50:03:782] 020000-03FFFF C43C96C3 C43C96C3 Same OperatingSystem
[12:50:10:621] 008000-01FFFF 9757EED8 BEAD23F3 Different Calibration
[12:50:13:031] 006000-007FFF D6B66D4D A4824A3C Different Parameter
[12:50:15:481] 004000-005FFF 85B5BB36 6AFFED87 Different Parameter
[12:50:18:361] 000000-003FFF 33AE0D6A 33AE0D6A Same Boot
[12:50:18:591] Note that mismatched Parameter blocks are to be expected.
[12:50:18:609] Parameter data can change every time the PCM is used.
[12:50:18:772] Clearing trouble codes.
[12:50:21:144] Elapsed time 00:01:06.9394111
There is definitely something broken / not working properly / unreliable there in hardware. As you say the read of 0x400 bytes at 0x004000 is failing and whats more it doesnt look right AND the data itself is inconsistent. Comparing the first two failed reads of the first block failing block and trimming the packet to fit the relevant bytes on single lines:
The data isnt consistent. FB BB becomes 7B BF. But the block checksum at the end doesn't change. This means the data is corrupted after the PCM has calculated the presumably correct block checksum, and its corrupted most likely in the VPW data stream on the wire. This probably means there is too much capacitance in your wiring affecting timing so that its borderline on what the interface can handle. I'd suggest shortening your cables / removing double adapters / unkinking the wires and try again. Failing that it could be a problem with your power supply being too noisy or with the interface itself. There is also a small possibility of corruption on the PCM around the VPW chip, but compared to the other options this is very unlikely, pretty much unheard of.
There is no point changing the OS, this is a hardware issue in your connection.
Oh you are right. I didn't notice that. I will change up the wiring and use a battery instead of a power supply.
Just to try it, I rebuilt the program without the if statement for the checksum and came up with this result. (log attached) It seems to just be in that section. I ran this twice and came back with different results in just that one section.
[07:33:56:282]
[07:33:56:316] Starting verification...
[07:33:56:337] Calculating CRCs from file.
[07:33:56:354] Initializing CRC algorithm on PCM, this will take a minute...
[07:33:56:588] Requesting CRCs from PCM.
[07:33:56:617] Range File CRC PCM CRC Verdict Purpose
[07:34:03:074] 060000-07FFFF D8C98FAF D8C98FAF Same OperatingSystem
[07:34:09:342] 040000-05FFFF 244EF6F9 244EF6F9 Same OperatingSystem
[07:34:15:730] 020000-03FFFF C43C96C3 C43C96C3 Same OperatingSystem
[07:34:21:045] 008000-01FFFF BEAD23F3 BEAD23F3 Same Calibration
[07:34:22:986] 006000-007FFF A4824A3C A4824A3C Same Parameter
[07:34:24:982] 004000-005FFF B0A310F3 871FD0A5 Different Parameter
[07:34:27:223] 000000-003FFF 33AE0D6A 33AE0D6A Same Boot
[07:34:27:335] ##############################################################################
[07:34:27:343] There are errors in the data that was read from the PCM. Do not use this file.
[07:34:27:351] ##############################################################################
[07:34:27:494] Clearing trouble codes.
[07:34:29:737] Clearing trouble codes.
[07:34:30:879] Elapsed time 00:11:03.0613048
[12:45:37:533] Starting verification...
[12:45:37:557] Calculating CRCs from file.
[12:45:37:581] Initializing CRC algorithm on PCM, this will take a minute...
[12:45:37:999] Requesting CRCs from PCM.
[12:45:38:072] Range File CRC PCM CRC Verdict Purpose
[12:45:46:690] 060000-07FFFF D8C98FAF D8C98FAF Same OperatingSystem
[12:45:55:071] 040000-05FFFF 244EF6F9 244EF6F9 Same OperatingSystem
[12:46:03:549] 020000-03FFFF C43C96C3 C43C96C3 Same OperatingSystem
[12:46:10:469] 008000-01FFFF BEAD23F3 BEAD23F3 Same Calibration
[12:46:12:776] 006000-007FFF A4824A3C A4824A3C Same Parameter
[12:46:15:166] 004000-005FFF AF1F649E 6AFFED87 Different Parameter
[12:46:18:035] 000000-003FFF 33AE0D6A 33AE0D6A Same Boot
[12:46:18:288] ##############################################################################
[12:46:18:305] There are errors in the data that was read from the PCM. Do not use this file.
[12:46:18:319] ##############################################################################
[12:46:18:523] Clearing trouble codes.
[12:46:20:899] Clearing trouble codes.
[12:46:23:122] Elapsed time 00:12:49.0239489
maybe there is something strange in its software. If its faulty before and you change os and its faulty after you wont be worse off, so maybe you should try flashing another bin on to it and see if it stays the same on subsequent reads or not? Especially if whats on it means nothing to you and you wont want to go back.
So I ended up using the file that I was able to read from the PCM with the bad blocks in 0x4000 and 0x5000. Deactivated VATs and some DTCs and was able to write the calibration. I didn't even touch the rest of the blocks. Will report back later on how it runs and drives.
I just revisited this thread with a fresh set of eyes and I realised you *verified* a downloaded file against your own pcm, you did not read and save the file. So, in that case, probably nothing was wrong in the first place. When I was here last I thought you read the bin off your pcm and it was changing in transit. The corrupted data was probably fine, and the difference from the online file and whats on the pcm is probably because it was tuned or not a 100% matching calibration, param blocks because it was a different car with different vin. The corrupt packet was probably legit corrupted, but corrected by pcmhammer on retry. sorry about that!
I just looked again and this did get a bit confusing. Here is everything I did in steps.
1. Tried reading the .bin file off of the PCM. It failed at 0x4000 due to a checksum error. So PCM Hammer wouldn't let me read the rest of the PCM.
2. Wanted to check if the entire memory was corrupted on the PCM so I tried verifying the PCM with the verify tool on PCM hammer. I figured a .bin of the same OS will be close enough for me to check the bootloader and operating system blocks of the PCM. This is so I can check the integrity of the rest of the file on the PCM. I used the file I downloaded from github. Verified the PCM against this file and it checked out fine so it led me to step 3.
3. Rebuild PCM Hammer and remove the if statement that checks the calculated checksum with the checksum at the end of block returned from the PCM. I did this so I can get the entire .bin file from the PCM without it failing at the checksum.
4. Readded the if statement for the checksum but this time to only set a log statement that tells me that a checksum is wrong in whatever block it is currently reading. This is how I found out that blocks 0x4000-0x4FFF and 0x5000-0x5FFF were returning bad results. The rest of the file that I read from the PCM was returning correctly.
5. Used the file I read from the PCM with bad blocks to deactivate VATs and some DTCs and wrote just the calibration to the PCM. So the bad blocks weren't getting written back to the PCM. This worked. Got the engine running.
My next step for this particular swap is to set the PCM to a manual transmission. It's throwing all the transmission codes at me and not wanting to stay running. I looked up one code that it returned (P1850) and google said that this is what would cause the engine not to want to stay running. I am not sure how true this is though.
So that is my next mission. Not sure how to do this yet though. This is my first time messing with these systems.
