PCM Hammer P12 development

[antus]

Good call, you could even not delay and just return and look for the response kur4o is talking about to confirm the upload and execute part, then add the watchdogs back in until you know they are working, then move on to the DLC.
Response on return would essentially be response for a kernel upload has to come from the kernel so that makes sense. I would say the response handler is more for errors, though they obviously put success in there as well, even if its not used.

[Gampy]

Good call ... Thy shall be done!

As I head off to

Edit; That made it really big ... 4 bytes!

It's just an empty routine ...

I have nothing to test this with, this is all it is,

Code: Select all

///////////////////////////////////////////////////////////////////////////////
// This is the entry point for the kernel.
///////////////////////////////////////////////////////////////////////////////
int
__attribute__((section(".kernelstart")))
KernelStart(void)
{
	//
	// Empty ...
	//
}

[Tazzi]

I thought when using the execute byte, the the code uploaded is direct ran thus its up to the kernel to respond?

Least this is how it worked for the canbus stuff (Obviously different protocol.. but should still follow same standards).

[Gampy]

Tazzi,

I strive to know half of what you know about this stuff, however the following is from a kernel that I know does not send that final 76 00 following the 3680 on a P01.

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.

[Tazzi]

Yeah, at that last frame:
36 80 04 00 FF 80 00

The "80" is to execute which would start at the 0xFF8000 location. Maybe some ECUs do respond, and others do not.
For CAN based ones, no response occurs, you have to actually send the 76 response back from the kernel.

[Gampy]

Next step, testing COPs ...

Last test, I'll let y'all decide ...

[email protected]

Spoiler alert ...

[09:16:00:706] TX: 6D 10 F0 36 80 00 04 FF 20 00 4E 75 00 00 02 66
[09:16:00:742] RX: 6C F0 10 76 00 73
[09:16:00:744] Found response, Success
[09:16:00:746] Kernel upload 100% complete.
[09:16:00:754] Kernel uploaded to PCM succesfully...

Just sent the simple delayed loop with dog scratcher routine as mentioned here out for testing.

[Gampy]

The dog ain't happy with my scratching, it didn't live.

So I added some nop's between COP2's bset, bclr ...

And sent a couple of tests.

[Gampy]

In that FFFF0000 disassembly, where is the entry point, is it FF2000, so sub_FFFF2404 is the first code ran ??

[Tazzi]

The dog ain't happy with my scratching, it didn't live.

So I added some nop's between COP2's bset, bclr ...

And sent a couple of tests.

So 55,AA at FA55 and then bit 7 switch at FA21?? Shouldnt be anymore then that??

[Gampy]

Code: Select all

#define WATCHDOG1                  (*(unsigned char *)0x00FFFA55)
#define WATCHDOG2                  (*(unsigned char *)0x00FFFA21)

void ScratchWatchdog()
{
  WATCHDOG1 = 0x55;
  WATCHDOG1 = 0xAA;
  WATCHDOG2 &= 0x7F;
  WATCHDOG2 |= 0x80;
}