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

ozpropdevozpropdev Posts: 2,540
edited 2016-11-02 - 11:08:44 in Propeller 2
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?


Melbourne, Australia
«1

Comments

  • evanhevanh Posts: 7,527
    edited 2016-11-02 - 07:12:43
    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.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanhevanh Posts: 7,527
    edited 2016-11-02 - 07:29:29
    [deleted]
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • 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.


    Melbourne, Australia
  • 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?
  • It appears the interrupt is being cancelled by the CALL instruction.
    I'm still digging....
    Melbourne, Australia
  • 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.
  • ozpropdev wrote: »
    In Pnut V12 ADRA & ADRB are now named PA & PB.

    Oh, why did Chip do that? That's overly terse.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • 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.
    Melbourne, Australia
  • 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/#
    



    Melbourne, Australia
  • CALLPA & CALLPB fail as well.
    Melbourne, Australia
  • cgraceycgracey Posts: 11,527
    edited 2016-11-02 - 10:05:10
    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.
  • Could the stack be getting corrupted?
  • cgraceycgracey Posts: 11,527
    edited 2016-11-02 - 10:21:47
    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.
  • 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.

    Melbourne, Australia
  • cgraceycgracey Posts: 11,527
    edited 2016-11-02 - 10:23:41
    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?
  • We need some kind of execution visualizer. That would clear things up, right away.
  • cgraceycgracey Posts: 11,527
    edited 2016-11-02 - 10:28:28
    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.
  • Yikes!
    Funny how something can be staring you in the face and you still miss it.
    It's clear now, oops!
    :(
    Melbourne, Australia
  • 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! :)
    Melbourne, Australia
  • 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.
  • Trouble being ME!
    How's the new compile looking?
    Melbourne, Australia
  • 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.
  • CALLD doesn't use the HW stack though, right? What failed with that attempt?
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • ozpropdevozpropdev Posts: 2,540
    edited 2016-11-03 - 01:59:48
    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.


    Melbourne, Australia
  • 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.
  • ozpropdevozpropdev Posts: 2,540
    edited 2016-11-04 - 08:52:39
    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   ,.`.............
    
    }
    


    Melbourne, Australia
  • cgraceycgracey Posts: 11,527
    edited 2016-11-04 - 09:52:26
    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.
  • Chip
    Is the problem i'm having with LOC instruction in the example code above linked to the CALLD problem?
    Melbourne, Australia
  • 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.
Sign In or Register to comment.