FIFO pointer and debug interrupt issue
ozpropdev
Posts: 2,792
in Propeller 2
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.
Am I breaking the rules again?
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?
Comments
- 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:
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.
It makes sense now.