V6 ability for pcm hammer.

[antus]

Im not sure what the 83 00 20 is, it might mean upload completed, but it breaks all the standards, so maybe not. I think we need to trust that the OS said it'd take the kernel, so it did. If there was something wrong with the arguments it would have sent an error. A dev kernel should try and send anything straight away to identify iteself as running at this stage of development. When I did the ls1flash read kernel, I got the DLC working, then had a function that just sent some vpw as a marker, and when I found a crash I'd move where I called that function from until I didnt see the response from it.

The 7F response shows its crashed because neither the read kernel or the write kernel have anything in the main loop that would generate that response. So if it cant do it, it must be the OS.

Because of the watchdog, and the way its built you'll (almost certainly) never get a crash where it just stops and needs power removed. It tends to reset and go back to the factory OS and you see standard responses like you would the same as if you threw packets at a locked pcm. you will see this a lot

[Gampy]

I do have the kernel sending a debug message upon execution, If it runs and can communicate I should know pretty quickly.

I call that the 'printf()' debugging technique ... I have no idea what others call it, haven't done much programming communication with others, always been a closet coder.

[edit]
BTW, I do test my kernel on a P01/59 frequently to ensure I haven't broke it.

[Gampy]

What would these logs lead one to believe??
P59

[09:19:04:544] TX: 36800542FF9000 ... Wacked data off.
[09:19:05:888] RX: 6D F0 10 76 00 73
[09:19:05:889] Found response, Success
[09:19:05:889] Kernel upload 100% complete.
[09:19:05:895] TX: STPX H:6C10F0, R:1, D:3D00
[09:19:06:240] RX: 6D F0 10 AA BB CC
[09:19:06:349] TX: STPX H:6C10F0, R:1, D:3D00
[09:19:06:959] RX: 6C F0 10 7D 00 08 02 04 CC
[09:19:06:960] Kernel Version: 080204CC
[09:19:06:962] kernel uploaded to PCM succesfully. Requesting data...

P04

[09:24:53:201] TX: 36800552FF9000 ... Wacked data off.
[09:24:57:833] Empty response to receive. That's not OK.
[09:24:57:845] Sending 'test device present' notification.
[09:24:57:853] TX: STPX H:8CFEF0, R:0, D:3F
[09:24:57:872] Empty response to STPX with data. That's OK
[09:25:00:110] Empty response to receive. That's not OK.
[09:25:00:118] Sending 'test device present' notification.
[09:25:00:126] TX: STPX H:8CFEF0, R:0, D:3F
[09:25:00:143] Empty response to STPX with data. That's OK
[09:25:02:382] Empty response to receive. That's not OK.

The only changes between them are ... 1) The device, 2) The DLC Addressing.
If one notices the kernel is loading at FF9000 on the P59 as well.

My debug "printf technique" ...
[09:19:06:240] RX: 6D F0 10 AA BB CC

Code: Select all

void DebugMsg()
{
	MessageBuffer[0] = 0x6D;
	MessageBuffer[1] = 0xF0;
	MessageBuffer[2] = 0x10;
	MessageBuffer[3] = 0xAA;
	MessageBuffer[4] = 0xBB;
	MessageBuffer[5] = 0xCC;
	WriteMessage(6, 1);
	LongSleepWithWatchdog();
}

Code: Select all

int
__attribute__((section(".kernelstart")))
KernelStart(void)
{
	DebugMsg();

	for(;;)
	{

As you can see I have removed everything upon entry.

P59: Looks good, it's working ...
P04: Leads me to believe the kernel is running and unable to talk back ...

[kur4o]

[09:24:53:201] TX: 36800552FF9000 ... Wacked data off.
[09:24:57:833] Empty response to receive. That's not OK.

It is because you are overwriting RAM that pcm uses for DLC communication. You can`t get the proper response and the jump to subroutine executed correctly because they are overwritten on the upload.
On earlier v6 OS the minimum for uploading is FF9090.
Use 38 00, 36 80 is not supported. Expect a 78 response byte if the upload is successful.

[Gampy]

It is because you are overwriting RAM that pcm uses for DLC communication. You can`t get the proper response and the jump to subroutine executed correctly because they are overwritten on the upload.
On earlier v6 OS the minimum for uploading is FF9090.
Use 38 00, 36 80 is not supported. Expect a 78 response byte if the upload is successful.

Awesome input, Thank you!
I totally agree, one must respect each others space!

So using 3800 means it is a single packet only??

[Gampy]

Bah Humbug ... First attempt.

[11:41:01:324] TX: 38000540FF9090 ... Wacked data off.
[11:41:05:924] Empty response to receive. That's not OK.
[11:41:05:925] Sending 'test device present' notification.
[11:41:05:925] TX: STPX H:8CFEF0, R:0, D:3F

Haven't given up on this though ... Gotta verify what I've done.

[Vampyre]

[09:24:53:201] TX: 36800552FF9000 ... Wacked data off.
[09:24:57:833] Empty response to receive. That's not OK.

It is because you are overwriting RAM that pcm uses for DLC communication. You can`t get the proper response and the jump to subroutine executed correctly because they are overwritten on the upload.
On earlier v6 OS the minimum for uploading is FF9090.
Use 38 00, 36 80 is not supported. Expect a 78 response byte if the upload is successful.

thank you, I did notice in the other flash programs 80 wasnt used.

[kur4o]

Sorry for the typo error.

It is 36 00, what I mean, and yes single upload only.

[Gampy]

[01:37:22:484] TX: 3600053CFF9090
[01:37:23:812] RX: 6D F0 10 76 00 78
[01:37:23:813] Found response, Success
[01:37:23:814] Kernel upload 100% complete.
[01:37:23:822] TX: STPX H:6C10F0, R:1, D:3D00
[01:37:27:116] Empty response to receive. That's not OK.
[01:37:27:240] TX: STPX H:6C10F0, R:1, D:3D00
[01:37:27:267] RX: 6C F0 10 7F 3D 00 11
[01:37:27:277] Kernel Version: 00000000
[01:37:27:284] kernel uploaded to PCM succesfully. Requesting data...

No response from kernel ... it has rebooted? or not executed the kernel?

[edit]
This is looking like it's going to need two kernels just for the P04 in the end, a skinny one to handle multi packets to bring the working kernel onboard ...

[Vampyre]

I get zero response with 38, would that be hammer saying no response since its not 76 or just no responce