PCM Hammer P12 development

[Gampy]

Latest log,

[05:54:44:176] VPW Explorer - P12 ONLY TEST Build 824.9.1.2 darkman5001 (2/22/2022, 3:12 PM)
[05:54:44:191] Initializing J2534 Device
[05:54:44:191] Loaded DLL
[05:54:44:191] Connected to the device.
[05:54:44:191] Battery Voltage is: 13.106
[05:54:44:191] Protocol Set
[05:54:44:191] Device initialization complete.
[05:55:12:389] Querying operating system of current PCM.
[05:55:12:405] TX: 6C 10 F0 3C 0A
[05:55:12:452] RX: 6C F0 10 7C 0A 00 C0 5B C0 41 41
[05:55:12:452] OSID: 12606400
[05:55:12:452] Suppressing VPW chatter.
[05:55:12:452] TX: 6C FE F0 28 00
[05:55:12:467] Sending 'test device present' notification.
[05:55:12:467] TX: 8C FE F0 3F
[05:55:12:483] RX: 6C F0 10 68 00
[05:55:12:483] Ignoring chatter: 6C F0 10 68 00
[05:55:12:483] Sending seed request.
[05:55:12:483] TX: 6C 10 F0 27 01
[05:55:12:514] RX: 6C F0 10 67 01 7A 9E
[05:55:12:514] Parsing seed value.
[05:55:12:530] Sending unlock request (7A9E, B05C)
[05:55:12:530] TX: 6C 10 F0 27 02 B0 5C
[05:55:12:561] RX: 6C F0 10 67 02 34
[05:55:12:561] Unlock succeeded.
[05:55:12:561] Sending 'test device present' notification.
[05:55:12:561] TX: 8C FE F0 3F
[05:55:12:561] Loaded M:\GM IMMO Testing\VPWExplorer\Test Kernels\micro-kernel-P12-824.9.1.4-FF2000.bin
[05:55:12:577] Sending upload request for kernel size 1204, loadaddress FF2000
[05:55:12:577] Requesting permission to upload kernel.
[05:55:12:577] TX: 6C 10 F0 34
[05:55:12:592] RX: 6C F0 10 74 00 44
[05:55:12:592] Found response, Success
[05:55:12:592] Upload permission granted.
[05:55:12:592] Going to load a 1204 byte kernel to 0xFF2000
[05:55:12:592] Sending end block payload with offset 0x0, start address 0xFF2000, length 0x4B4.
[05:55:12:592] Sending 'test device present' notification.
[05:55:12:592] TX: 8C FE F0 3F
[05:55:12:671] TX: 6D 10 F0 36 00 04 B4 FF 20 00 . . . . . . . . . . . Wacked for brevity
[05:55:13:639] RX: 6C F0 10 76 00 73
[05:55:13:639] Found response, Success
[05:55:13:639] Kernel upload 100% complete.
[05:55:13:639] Kernel uploaded to PCM succesfully...
[05:55:13:639] Sending 'test device present' notification.
[05:55:13:639] TX: 8C FE F0 3F
[05:56:05:941] TX: 6C 10 F0 3D 00
[05:56:05:941] RX: 6C F0 10 7F 3D 00 11
[05:56:05:941] Kernel Version: 00000000

The kernel is not running, it immediately accepts a second kernel upload, if the kernel was running it would not do so ...

[kur4o]

I trace some code. If you send 3680 it will upload and execute silently. No response before execute.

To confirm data flow. send on purpose mode 3600 with wrong block checksum and message length. If you get 72 or 77 response it will be good.

[Gampy]

It refuses mode 34 with size and address ...

Sure wish I had an sps log or the like.

An SPS log? Tell me exactly what you need. I have SPS on standalone.

Sorry missed this.

A log of a flash transaction on a P12, you already soft bricked one with the Tech2, lets not do another!

[antus]

36 00 is upload 36 80 is upload and execute. Eg submode bit 7 is jump to this address after accepting the upload. if its a 1 packet kernel you need the 36 80. If its more than one, it might need to be a single packet like the P04 because it might not support multi-part uploads.

[Gampy]

Like I've stated, it has never responded to a mode 36 80 at all, it just goes silent!
This is the first time the P12 has responded to a mode 36 at all.

If it is limited to a single packet mode36, it stands to reason that it is 36 00 ... Just like the P04, and the P04 does respond with success before it jumps to the kernel.

It is possible that 36 80 silently jumps to the kernel without announcing success, I find this hard to believe, I believe it will announce success before jumping to the kernel.
I've have been wrong before, I have no doubt I'll be wrong again sometime in my life, it's a fact of all human life!

Everything I have done with Automotive controllers (not much), has always responded to a command, always ... Whether it responds with data or a success/failure code, it at least responds.

This P12 is NOT responding to 36 80 at all, but as the log proves it responds to 36 00.
BTW, I'm pretty sure (would have to re-read the thread), this is exactly what the P04 did, it does not respond to 36 80 either.

[antus]

how does that compare to pcmhammer? I know I wrote a bunch of pcmhammer so its a strange question but its hard to remember the specific protocol details when its not in recent memory. I thought the pcm didnt respond and the kernel did, but I could very easily have that wrong.

[kur4o]

Code: Select all

ROM:000A72C8 loc_A72C8:                              ; CODE XREF: M36_sub_A71E2+D0j
ROM:000A72C8                 cmp.b   #$80,d4
ROM:000A72CC                 bne.s   loc_A72D2
ROM:000A72CE                 movea.l d6,a0
ROM:000A72D0                 jsr     (a0)
ROM:000A72D2
ROM:000A72D2 loc_A72D2:                              ; CODE XREF: M36_sub_A71E2+EAj
ROM:000A72D2                 moveq   #$73,d6 ; 's'
ROM:000A72D4
ROM:000A72D4 loc_A72D4:                              ; CODE XREF: M36_sub_A71E2+80j
ROM:000A72D4                 clr.l   -(sp)
ROM:000A72D6                 clr.l   -(sp)
ROM:000A72D8                 move.l  d6,-(sp)
ROM:000A72DA                 move.b  5(a5),d0
ROM:000A72DE                 move.l  d0,-(sp)
ROM:000A72E0                 bsr.w   Send_short__sub_A718A

Digg some more code. You will get response from 3680 after the code is executed and control is returned to pcm.

You can test this by uploading some very simple rtn code that do nothing.

[Gampy]

The P01/P59 PCM Hammer process goes like this ...

[10:49:46:813] TX: 6C10F034001000FF8000
[10:49:46:852] RX: 6C F0 10 74 00 44
.
. . . . . . . . . . Wacked for brevity.
.
[10:49:46:900] TX: 360003F0FF9C00 . . . . . . . . . Wacked for brevity.
[10:49:47:924] RX: 6D F0 10 76 00 73
.
. . . . . . . . . . Wacked for brevity.
.
[10:49:54:274] TX: 36800400FF8000 . . . . . . . . . Wacked for brevity.
[10:49:55:314] RX: 6D F0 10 76 00 73

At this point the kernel is in control until we allow the WatchDog to run out causing the PCM to reboot.

You will get response from 3680 after the code is executed and control is returned to pcm.

That doesn't make logical sense (to me at least), why would the PCM respond after it's returned from executing the kernel code ... The PCM is rebooted to exit the kernel code.

[kur4o]

The reason might be that this mode is strictly to run some code and return control to pcm. Actually on flashing the communication loop is run by code in pcm. The boot block never gets erased or updated. The loaded flash routine have no communiation loop and never takes completely full control. Something like additional code that handles erase and program only.

So you got response when the uploaded code is excuted succesfully and pcm is control again.

[Gampy]

Ok, I'm going in a different direction, instead of a kernel that takes control, a simple routine (a whoping 154 bytes) that returns control to the PCM ... It's a simple delayed loop with dog scratcher, should live about 45 seconds!

I'm going to send it using 3680, at address FF2000, using COPs FA55 and FA21.

That test will be ready to send in nano or two ...