FIFO pointer and debug interrupt issue

Hi Chip

I'm having an issue trying to use RFVAR from within a debug interrupt service routine.
The fifo pointer address set with RDFAST is lost on entry to the ISR.
It seems that the fifo pointer address is being replaced with $FFFC8 + cogid << 2.
These values I can confirm with a GETPTR instruction.

Here's some test code for P123-A9 to show the issue.

If you change the "test_cog" value you will see the values mentioned above.
If the debug interrupt is dusabled the value counts from $f00 ok.
con
		sys_clk = 60_000_000
		test_cog = 0

dat		orgh
		org

		wrlong	isr,##$FFFC0 + test_cog << 2   'comment out to disable debug

		coginit	#test_cog,##@mycode
		cogstop	#0

isr		jmp	#\my_isr

		orgh	$400
		org

mycode		bmask	dirb,#15
		rdfast	#0,##$f00	'set fifo start address to $f00

again		rfbyte	pa		'dummy byte read
		getptr	outb		'leds <= fifo address
		waitx	##sys_clk
		jmp	#again

my_isr		setbrk	#1
		reti0



Am I breaking the rules again? :)
Melbourne, Australia

Comments

  • 4 Comments sorted by Date Added Votes
  • I'm running your code and trying to figure this out. I'm stumped at the moment.
  • That $FFFC8 + cogid<<2 would be the address AFTER the normal RETI0 was executed, considering that the trailing instruction would have been read into the pipeline, as well. Remember that jumping to $FFFC0+ would invoke hub exec and would override the current RDFAST. However, we are preempting the jump to $FFFC0+ by repointing to $008 here (my_isr). Still working on this...
  • cgraceycgracey Posts: 7,835
    edited May 23 Vote Up0Vote Down
    Okay. Here's the way this works:

    - On COGINIT, within the cog being started, INA's shadow RAM register is initialized to $FFFC0 + COGID << 2.
    - Before any of your code runs, a debug interrupt occurs, executing a 'CALLD INB,INA' (INA/INB are shadow RAM).
    - The instruction at $FFFC0 + COGID << 2 is fetched and executed (hub exec).
    - If you have overridden the default RETI0 by placing a JMP at $FFFC0 + COGID << 2, your *initial* debug ISR will execute.
    - Your initial debug ISR must repoint INA to a cog address ($000..$3FF) where a debug ISR exists, in order to not cause a hub exec jump on the next debug interrupt.
    - Once the debug ISR pointed to is in cog space, no hub exec jumps to $FFFC0 + COGID << 2 will occur and upset your RDFAST activity.

    Here I added one instruction to your debug ISR to repoint INA to itself, so that on the next debug interrupt, it will jump directly there, bypassing the jump at the top of memory, thereby avoiding a disruptive hub exec RDFAST:
    my_isr		mov	ina,#my_isr
    		setbrk	#1
    		reti0
    

    You could make separate 'initial' and 'subsequent' ISR's, where you don't need to do the 'mov ina,#my_isr' every time, but it's maybe not worth doing, unless you had some special initial setup you wanted to do.
  • Thanks for working that out Chip.
    It makes sense now. :)

    Melbourne, Australia
Sign In or Register to comment.