PCM Hammer P12 development

[antus]

Well, I took your diffs gampy and patched them against current pcmhammer develop and got it to the point I could mostly reproduce your results. Bin reading is fine and reliable. I can ID the flash. But things go bad at erase. Ive been comparing other tools and the pcmhammer code, and come to the conclusion that triggering the flash erase is right in the context of the flash data sheet, but there are more and different registers involved that we dont have a handle on yet. Im not sure how you erased a sector, and Im playing with the unused param block which is blank anyway so maybe it is erasing but the pcm is definitely crashing before we get a clean erase exit and we're going to have to figure out more hardware before we do this right.

[Gampy]

Then you have something amiss ... I know for a fact that what I had does NOT crash the PCM!

It's extremely easy to pick this out with a logger running ...

If you want to zip and ship your kernel code, I'll have a look see, but something is not right.

[Gampy]

Your kernel runs fine, however there are a couple issues,

1. It crashes on exit because important exit changes have not been completed.
. . It may be ugly the quick and dirty way I've done it, but the technique is required!

2. It's dumb and probably returned an error code 0f FF FF, you did the same thing I did, forgot to add the case statements to,

Code: Select all

void HandleEraseBlock()

and

Code: Select all

unsigned char WriteToFlash(unsigned int payloadLengthInBytes, unsigned int startAddress, unsigned char *payloadBytes, int testWrite)

In write-kernel.c

NOTE: Allowing the COP to run out versus cleanly exiting leaves the PCM in an unstable state.
The only other clean option I found was with the use of asm("reset"), asm("stop ...") also leaves the PCM in an unstable state ...

[antus]

Yep i'm on it. Im doing things a bit differently and building on your work. Will report back when there is something to report.

[antus]

much more testing required, but Im just gonna leave this here....
Param block because its a safe place. Just a 'hello world' to the unused segment, if success or failure, no damage to the pcm. the other valid param block is used and the OS and the Cal remain intact.

[Tazzi]

Nice job!!!

[antus]

I was able to clone your I5 bin in to my PCM, Gampy

Maybe all the boot sectors are the same, thats going to make it hard/risky to test.

So this confirms the slave cpu doesnt need anything special, a single kernel works just fine.

Block retrys are probably just tuning the delays, pcmhammer had a few retries like this in the first few releases until we timed the kernel better. 1 or 2 transmission retries for a segment are no big deal, though.

I think we might need to get some help from NSFW to get the code changes merged in to the main app in a clean way. Now we are going to need XDFs too.

Code: Select all

[04:12:31:999]  PCM Hammer (28/03/2022, 7:41 PM)
[04:12:32:157]  AVT 852 Reset OK
[04:12:32:167]  AVT Firmware 1.5
[04:12:47:372]  C:\Users\a\Downloads\2006_Colorado_3.5L(I5)L52_Os12606375.bin
[04:12:47:378]  Validating 1024k file.
[04:12:47:381]  Requesting operating system ID...
[04:12:47:486]  Operating system IDs do not match.
[04:12:47:488]  PCM operating system ID: 12627883
[04:12:47:491]  File operating system ID: 12606375
[04:12:47:493]  Changing PCM to operating system 12606375
[04:12:47:657]  Unlock succeeded.
[04:12:47:726]  Attempting switch to VPW 4x
[04:12:47:768]  Module 0x10 (engine controller) has agreed to enter high-speed mode.
[04:12:50:889]  Requesting permission to upload kernel.
[04:12:50:909]  Upload permission granted.
[04:12:51:784]  Kernel upload 49% complete.
[04:12:52:676]  Kernel upload 100% complete.
[04:12:53:790]  Kernel Version: 010303BB
[04:12:53:796]  Kernel uploaded to PCM succesfully.
[04:12:53:868]  Changing PCM to operating system 12606375
[04:12:53:931]  Flash chip: AMD AM29BL802C, 1mb
[04:12:53:944]  Calculating CRCs from file.
[04:12:53:963]  Initializing CRC algorithm on PCM, this will take a minute...
[04:12:54:061]  Requesting CRCs from PCM.
[04:12:54:065]  	Range		File CRC		PCM CRC	Verdict	Purpose
[04:12:58:186]  0C0000-0FFFFF	9E9AA4FE	A20403CE	Different	OperatingSystem
[04:13:02:187]  080000-0BFFFF	DC4C00BC	07D88245	Different	OperatingSystem
[04:13:04:180]  060000-07FFFF	75F3CEFF	5873C959	Different	OperatingSystem
[04:13:06:258]  040000-05FFFF	E0E2649D	171C3966	Different	OperatingSystem
[04:13:08:305]  020000-03FFFF	1D5E36DC	9A697ED2	Different	Calibration
[04:13:09:931]  008000-01FFFF	9F5568C7	74ED412A	Different	Calibration
[04:13:10:208]  006000-007FFF	192F3CB1	646B7583	Different	Parameter
[04:13:10:484]  004000-005FFF	85B5BB36	2803BBE1	Different	Parameter
[04:13:10:893]  000000-003FFF	7EBCD52C	7EBCD52C	Same	Boot
[04:13:10:916]  Processing range 0C0000-0FFFFF
[04:13:10:939]  Erasing.
[04:13:16:595]  Writing...
[04:14:40:518]  Retry count for this block: 2
[04:14:40:527]  Processing range 080000-0BFFFF
[04:14:40:537]  Erasing.
[04:14:46:074]  Writing...
[04:16:09:940]  Retry count for this block: 2
[04:16:09:949]  Processing range 060000-07FFFF
[04:16:09:959]  Erasing.
[04:16:14:526]  Writing...
[04:16:56:504]  Retry count for this block: 1
[04:16:56:514]  Processing range 040000-05FFFF
[04:16:56:524]  Erasing.
[04:17:01:012]  Writing...
[04:17:42:742]  Retry count for this block: 1
[04:17:42:752]  Processing range 020000-03FFFF
[04:17:42:763]  Erasing.
[04:17:46:344]  Writing...
[04:18:27:591]  Retry count for this block: 1
[04:18:27:601]  Processing range 008000-01FFFF
[04:18:27:612]  Erasing.
[04:18:31:923]  Writing...
[04:19:04:275]  Retry count for this block: 1
[04:19:04:286]  Processing range 006000-007FFF
[04:19:04:297]  Erasing.
[04:19:04:822]  Writing...
[04:19:07:185]  Processing range 004000-005FFF
[04:19:07:195]  Erasing.
[04:19:07:814]  Writing...
[04:19:10:179]  Calculating CRCs from file.
[04:19:10:195]  Initializing CRC algorithm on PCM, this will take a minute...
[04:19:10:289]  Requesting CRCs from PCM.
[04:19:10:300]  	Range		File CRC		PCM CRC	Verdict	Purpose
[04:19:14:147]  0C0000-0FFFFF	9E9AA4FE	9E9AA4FE	Same	OperatingSystem
[04:19:17:913]  080000-0BFFFF	DC4C00BC	DC4C00BC	Same	OperatingSystem
[04:19:19:892]  060000-07FFFF	75F3CEFF	75F3CEFF	Same	OperatingSystem
[04:19:21:960]  040000-05FFFF	E0E2649D	E0E2649D	Same	OperatingSystem
[04:19:24:063]  020000-03FFFF	1D5E36DC	1D5E36DC	Same	Calibration
[04:19:25:600]  008000-01FFFF	9F5568C7	9F5568C7	Same	Calibration
[04:19:25:898]  006000-007FFF	192F3CB1	192F3CB1	Same	Parameter
[04:19:26:196]  004000-005FFF	85B5BB36	85B5BB36	Same	Parameter
[04:19:26:618]  000000-003FFF	7EBCD52C	7EBCD52C	Same	Boot
[04:19:26:698]  All relevant ranges are identical.
[04:19:26:715]  Write-request messages had to be re-sent 8 times.
[04:19:26:731]  We're not sure how much retrying is normal for a write operation on a 1024kb PCM.
[04:19:26:746]  Please help by sharing your results in the PCM Hammer thread at pcmhacking.net.
[04:19:26:762]  Flash successful!
[04:19:26:839]  Clearing trouble codes.
[04:19:27:941]  Elapsed time 00:06:40.2819211

[Gampy]

Good job!

[Gampy]

Antus,

Can you do the recommended steps of,
1. Read Entire PCM
2. Test Write
3. Write Calibration

[antus]

Yes, these things are working for me. I have also flashed in all the bins we have without trouble. Notable exceptions are exit kernel does not seem to work - it needs a reboot. the get hardware ID does not seem to work. the data might be valid, and we might need to handle the response differently for P12, or not even try. and ive not seen a boot block written since all the bins we have, have the same boot block. I reckon it would work but its untested and we also dont hae a test case. I think the biggest thing we need is for the protocol/message class to be able to know what type of PCM it is, so we can remove the #if and set it up so that it can work on P01/P59/P12 without two versions of the software.