COG/LUT exec,streamer and interrupts acting weird [SOLVED]

ozpropdev · 2016-11-02 03:23

Hi Chip

I am experiencing an issue using a lut based isr VGA video driver with cog code.
I assumed that because the LUT is dual port ram the streamer can access lut at the same time as LUT exec does.
This seems to be the case as the driver works nicely and the image is rock solid.

The problem is that a CALL in cog ram to cog ram causes the video driver to fail.

In the included code a PAUSE is done in straight code which works fine.
If that code is replaced with a CALL to identical code the video driver fails.
The CALL'd routine is working correctly and is verified by the LED activity.

Is it simply that the lut based isr video driver shouldn't have worked in the first place?
Have I broken a rule and pushed my luck again?

evanh · 2016-11-02 07:07

Interrupts don't use the HW stack as far as I know, only 3 deep used there I think, so that shouldn't be a problem.

I do get an "Undefined symbol" for variable pb. EDIT: Ah, I see that's meant to be ptrb.

evanh · 2016-11-02 07:21

[deleted]

ozpropdev · 2016-11-02 08:22

evanh wrote: »

I do get an "Undefined symbol" for variable pb. EDIT: Ah, I see that's meant to be ptrb.

In Pnut V12 ADRA & ADRB are now named PA & PB.

cgracey · 2016-11-02 08:51

I haven't run your code yet, but the second LUT access port is only used by two things: the streamer (read-only) and LUT sharing with adjacent cog (read/write). So, there should be no conflict there.

Have you made any new discoveries?

ozpropdev · 2016-11-02 08:56

It appears the interrupt is being cancelled by the CALL instruction.
I'm still digging....

cgracey · 2016-11-02 09:00

ozpropdev wrote: »

It appears the interrupt is being cancelled by the CALL instruction.
I'm still digging....

I've been really stumped a few times, myself, so far, when writing Prop2 software. Hopefully, we can have good single-stepping tools that let us see where these problems lie, as they've tied me up for half a day, on occasion.

evanh · 2016-11-02 09:24

ozpropdev wrote: »

In Pnut V12 ADRA & ADRB are now named PA & PB.

Oh, why did Chip do that? That's overly terse.

ozpropdev · 2016-11-02 09:27

Swapped CALL for a CALLD alternative and it fails too.
If I JMP to the routine and use a JMP instead of a RET to return back the code works.

ozpropdev · 2016-11-02 09:33

evanh wrote: »

ozpropdev wrote: »

In Pnut V12 ADRA & ADRB are now named PA & PB.

Oh, why did Chip do that? That's overly terse.

V12
New 'CALLPA/CALLPB D/#,S/#' instructions write D/# to PA/PB and call S/#

ozpropdev · 2016-11-02 09:37

CALLPA & CALLPB fail as well.

cgracey · 2016-11-02 10:04

evanh wrote: »

ozpropdev wrote: »

In Pnut V12 ADRA & ADRB are now named PA & PB.

Oh, why did Chip do that? That's overly terse.

The CALLPA and CALLPB mnemonics are about as long as they can be. I figured that PA and PB could mean 'pointer' or 'parameter', as they now serve both purposes.

cgracey · 2016-11-02 10:06

Could the stack be getting corrupted?

cgracey · 2016-11-02 10:17

You seem to be doing CALLs and RETs within your ISR, and then doing CALLs and RETs outside your ISR:

hsync		xcont	m_bs,#0			'horizontal sync
		resi1
		xcont	m_sn,#1
		resi1
		xcont	m_bv,#0
		testin	#32 wc
		outnc	#34			'isr running LED
		resi1
		ret

That will jumble up the stack.

I would make the ISR code so that it does each step and then an RESI1, and use variables that only it touches to keep track of counters. The PC can be maintained across interrupts via the RESI1 instructions.

Any CALLs and RETs that you do in your ISR would have to fully RETurn, so as not to corrupt the stack for your mainline code.

ozpropdev · 2016-11-02 10:17

The CALL's seem to execute the addressed routine and return Ok.
If I PUSH a value onto the stack before I make the CALL I can POP the correct value off the stack after the CALL.

cgracey · 2016-11-02 10:23

ozpropdev wrote: »

The CALL's seem to execute the addressed routine and return Ok.
If I PUSH a value onto the stack before I make the CALL I can POP the correct value off the stack after the CALL.

But isn't that all punctuated by interrupts that expect stack values to survive between interrupts, while your main code does CALLs, too?

cgracey · 2016-11-02 10:24

We need some kind of execution visualizer. That would clear things up, right away.

cgracey · 2016-11-02 10:27

I think of interrupts as something I want to get out of ASAP, since hanging around too long stalls the mainline code and can even cause missed interrupts if they are being triggered rapidly. Imagine that while you are in an interrupt, you are on stolen time and you need to get out as quick as you can, before you get caught in some unfortunate conundrum that brings everything to a halt. You can't do anything if you wind up in jail.

ozpropdev · 2016-11-02 10:45

Yikes!
Funny how something can be staring you in the face and you still miss it.
It's clear now, oops!

ozpropdev · 2016-11-02 10:56

I'm trying to squeeze some code into a 1 cog Nano and produce video too.
The streamer locks out hubexec so running the video stuff in LUT frees up cog ram for the main code.
Thanks for setting me straight Chip!

cgracey · 2016-11-02 11:05

ozpropdev wrote: »

I'm trying to squeeze some code into a 1 cog Nano and produce video too.
The streamer locks out hubexec so running the video stuff in LUT frees up cog ram for the main code.
Thanks for setting me straight Chip!

No problem. Glad we know what the trouble was.

ozpropdev · 2016-11-02 11:07

Trouble being ME!
How's the new compile looking?

cgracey · 2016-11-02 11:41

ozpropdev wrote: »

Trouble being ME!
How's the new compile looking?

I've got the Prop123_A9 compiled and am waiting on the BeMicro_A9 right now. Once these two are out of the way, the rest go quickly. I've got the doc's updated, except for the serial loader changes. It's in a new file, not the currently-linked one. I really want to get this next release out, because I think it's pretty final.

evanh · 2016-11-02 23:07

CALLD doesn't use the HW stack though, right? What failed with that attempt?

ozpropdev · 2016-11-03 01:46

evanh wrote: »

CALLD doesn't use the HW stack though, right? What failed with that attempt?

It looks like their is an issue with Pnut and CALLD D,#rel9.

CALLD myret,#pause  'fails
CALLD myret,@pause  'fails
CALLD myret,#@pause  ' fails
however
CALLD myret,_pause  'works
.
.
_pause    long    pause

This added to the whole "what going on?" scenario.

ozpropdev · 2016-11-03 03:37

This has caught me out once before.
http://forums.parallax.com/discussion/163083/pnut-problem-with-calld-when-calling-from-a-cog-address-to-another-cog-address

cgracey · 2016-11-03 10:32

In PNut.exe, some improvements have been made to the relative/absolute addressing used by branch instructions. It's likely that some weirdness you've experienced with branches could be fixed by the new release.

ozpropdev · 2016-11-04 06:29

I'm still struggling with CALLD D,#rel9 in Pnut and some addressing issues.

The following example moves some code from hub to lut and then uses a CALLD instruction to call lut.
I had to manually encode the LOC and CALLD instructions to get it to work.

dat	orgh
	org

	loc	ptra,#code		'FC 07 D0 FE	'fails
	loc	ptra,#\code		'00 02 C0 FE	'fails
	loc	ptra,#@code		'94 00 D0 FE	'fails

'manually encode loc ptra,#nnnn instruction
	long	$fec00000 | @code	'28 00 C0 FE 	'works

	setq2	#100			'copy code to lut
	rdlong	0,ptra

	or	dirb,##$ffff		'enable leds
	jmp	#code			'jump to lut

myret	long	0

	org	$200

code
'	calld	myret,#@leds5	'Pnut error - D register must be PA/PB/PTRA/PTRB
'	calld	myret,#leds5	'Pnut error - D register must be PA/PB/PTRA/PTRB
'	calld	myret,@leds5	'Pnut Ok, code fails

'manually encode CALLD reg,#rel9 instruction
me	long	$fb240000 | myret << 9 | leds5 - me - 1 'works

here	jmp	#here

leds16	outh	#32
	outh	#33
	outh	#34
	outh	#35
	outh	#36
	outh	#37
	outh	#38
	outh	#39

	outh	#40
	outh	#41
leds6	outh	#42
leds5	outh	#43
	outh	#44
leds3	outh	#45
	outh	#46
leds1	outh	#47

	jmp	myret


{
TYPE: 55   VALUE: 00900024   NAME: MYRET
TYPE: 55   VALUE: 20000028   NAME: CODE
TYPE: 55   VALUE: 20000028   NAME: ME
TYPE: 55   VALUE: 2010002C   NAME: HERE
TYPE: 55   VALUE: 20200030   NAME: LEDS16
TYPE: 55   VALUE: 20C00058   NAME: LEDS6
TYPE: 55   VALUE: 20D0005C   NAME: LEDS5
TYPE: 55   VALUE: 20F00064   NAME: LEDS3
TYPE: 55   VALUE: 2110006C   NAME: LEDS1

OBJ bytes:     128

_CLKMODE: 00
_CLKFREQ: 00B71B00

00000- FC 07 D0 FE 00 02 C0 FE 94 00 D0 FE 28 00 C0 FE   ............(...
00010- 17 C8 64 FD 00 01 04 FB 7F 00 00 FF FF F7 47 F5   ..d...........G.
00020- DC 07 90 FD 00 00 00 00 0C 10 24 FB FC FF 9F FD   ..........$.....
00030- 49 40 64 FD 49 42 64 FD 49 44 64 FD 49 46 64 FD   I@d.IBd.IDd.IFd.
00040- 49 48 64 FD 49 4A 64 FD 49 4C 64 FD 49 4E 64 FD   IHd.IJd.ILd.INd.
00050- 49 50 64 FD 49 52 64 FD 49 54 64 FD 49 56 64 FD   IPd.IRd.ITd.IVd.
00060- 49 58 64 FD 49 5A 64 FD 49 5C 64 FD 49 5E 64 FD   IXd.IZd.I\d.I^d.
00070- 2C 12 60 FD 00 00 00 00 00 00 00 00 00 00 00 00   ,.`.............

}

cgracey · 2016-11-04 09:51

ozpropdev wrote: »

I'm still struggling with CALLD D,#rel9 in Pnut and some addressing issues.

The following example moves some code from hub to lut and then uses a CALLD instruction to call lut.
I had to manually encode the LOC and CALLD instructions to get it to work.

dat	orgh
	org

	loc	ptra,#code		'FC 07 D0 FE	'fails
	loc	ptra,#\code		'00 02 C0 FE	'fails
	loc	ptra,#@code		'94 00 D0 FE	'fails

'manually encode loc ptra,#nnnn instruction
	long	$fec00000 | @code	'28 00 C0 FE 	'works

	setq2	#100			'copy code to lut
	rdlong	0,ptra

	or	dirb,##$ffff		'enable leds
	jmp	#code			'jump to lut

myret	long	0

	org	$200

code
'	calld	myret,#@leds5	'Pnut error - D register must be PA/PB/PTRA/PTRB
'	calld	myret,#leds5	'Pnut error - D register must be PA/PB/PTRA/PTRB
'	calld	myret,@leds5	'Pnut Ok, code fails

'manually encode CALLD reg,#rel9 instruction
me	long	$fb240000 | myret << 9 | leds5 - me - 1 'works

here	jmp	#here

leds16	outh	#32
	outh	#33
	outh	#34
	outh	#35
	outh	#36
	outh	#37
	outh	#38
	outh	#39

	outh	#40
	outh	#41
leds6	outh	#42
leds5	outh	#43
	outh	#44
leds3	outh	#45
	outh	#46
leds1	outh	#47

	jmp	myret


{
TYPE: 55   VALUE: 00900024   NAME: MYRET
TYPE: 55   VALUE: 20000028   NAME: CODE
TYPE: 55   VALUE: 20000028   NAME: ME
TYPE: 55   VALUE: 2010002C   NAME: HERE
TYPE: 55   VALUE: 20200030   NAME: LEDS16
TYPE: 55   VALUE: 20C00058   NAME: LEDS6
TYPE: 55   VALUE: 20D0005C   NAME: LEDS5
TYPE: 55   VALUE: 20F00064   NAME: LEDS3
TYPE: 55   VALUE: 2110006C   NAME: LEDS1

OBJ bytes:     128

_CLKMODE: 00
_CLKFREQ: 00B71B00

00000- FC 07 D0 FE 00 02 C0 FE 94 00 D0 FE 28 00 C0 FE   ............(...
00010- 17 C8 64 FD 00 01 04 FB 7F 00 00 FF FF F7 47 F5   ..d...........G.
00020- DC 07 90 FD 00 00 00 00 0C 10 24 FB FC FF 9F FD   ..........$.....
00030- 49 40 64 FD 49 42 64 FD 49 44 64 FD 49 46 64 FD   I@d.IBd.IDd.IFd.
00040- 49 48 64 FD 49 4A 64 FD 49 4C 64 FD 49 4E 64 FD   IHd.IJd.ILd.INd.
00050- 49 50 64 FD 49 52 64 FD 49 54 64 FD 49 56 64 FD   IPd.IRd.ITd.IVd.
00060- 49 58 64 FD 49 5A 64 FD 49 5C 64 FD 49 5E 64 FD   IXd.IZd.I\d.I^d.
00070- 2C 12 60 FD 00 00 00 00 00 00 00 00 00 00 00 00   ,.`.............

}

I've been looking over the CALLD code in the assembler. There are some problems that I thought I had really delved into recently and tuned up. I will get it fixed soon.

ozpropdev · 2016-11-04 10:15

Chip
Is the problem i'm having with LOC instruction in the example code above linked to the CALLD problem?

cgracey · 2016-11-04 16:37

ozpropdev wrote: »

Chip
Is the problem i'm having with LOC instruction in the example code above linked to the CALLD problem?

It could be. I remember totally revamping that a week or two ago, but the source code looks like it used to. I might have moved a file the wrong direction, or something. I'm going to Parallax today to get the test chips mounted on the new PCBs and see how they work. I will get back on the assembler code tonight.

COG/LUT exec,streamer and interrupts acting weird [SOLVED]

Comments