Shop OBEX P1 Docs P2 Docs Learn Events
COGATN causes erratic Pnut F11 download behaviour — Parallax Forums

COGATN causes erratic Pnut F11 download behaviour

ozpropdevozpropdev Posts: 2,792
in Propeller 2
Chip
In the included code which generates a VGA image if I include the COGATN instruction it randomly fails after a F11 download from Pnut.
If I remove the COGATN instruction it downloads OK every time.

Target board is P123-A9. Any clues?
spin
spin
cogatn.spin
3K
«1

Comments

  • ozpropdevozpropdev Posts: 2,792
    Also seeing same behaviour on DE2-115.
    No video output but background code runs oK.
  • ozpropdevozpropdev Posts: 2,792
    Adding to the range of tests the code runs OK on DE0-Nano with adapter board.
  • cgraceycgracey Posts: 14,152
    The code seems to run on a Prop123-A9 board, although it's configured as a two-cog chip.
  • cgraceycgracey Posts: 14,152
    I will try the DE2-115 in the morning.

    Thanks for conveying this problem.
  • ozpropdevozpropdev Posts: 2,792
    cgracey wrote: »
    The code seems to run on a Prop123-A9 board, although it's configured as a two-cog chip.
    It seems to be Ok on a 2 cog configuration (DE0-Nano).
    I just ran the P123-A9 again and it failed 5 times in 20 downloads.

  • SeairthSeairth Posts: 2,474
    What are the symptoms that it's gone wrong? I haven't yet hooked up a VGA monitor, but the upload on my A9 appears to work fine (and GRN7 is blinking).
  • ozpropdevozpropdev Posts: 2,792
    No video output is the symptom, yet green led blinks every time.
    Fails ~1 in 5 downloads.


  • evanhevanh Posts: 15,915
    Oz,
    What is the RESI1 instruction?
  • ozpropdevozpropdev Posts: 2,792
    evanh wrote: »
    Oz,
    What is the RESI1 instruction?
    It's a return from interrupt except it loads the interrupt vector with the next address. (Resume?)


  • evanhevanh Posts: 15,915
    The next instruction after the RESI? ... so it's an event based task scheduler? That's a scary simple!
  • evanhevanh Posts: 15,915
    I think it's missing from the docs.
  • ozpropdevozpropdev Posts: 2,792
    From the V9 docs - INTERRUPTS 
    The CALLD, with D = <any register>, S = IRETx, and WC,WZ, signals the cog that the interrupt is complete. This
causes the cog to clear its internal interruptbusy
flag for that interrupt, so that another interrupt can occur. INB
(readonly)
is used as D for RETIx instructions to effectively make the CALLD into a JMP back to the interrupted
code. Instead of using RETIx, though, you could use ‘CALLD IJMPx,IRETx WC,WZ’ to have your ISR resume at
the next instruction when the next interrupt occurs
    and from instructions_v9.txt - ALIASES 
    RESI1                           =       CALLD   $1F4,$1F5   WC,WZ


  • evanhevanh Posts: 15,915
    One question is: What would happen if the video driver was somehow being loaded into Cog #1 instead of, I presume, Cog#0? Would the COGATN#1 interfere with those Streamer events?

    What will the other Cog do if it never receives it's attention event?
  • evanhevanh Posts: 15,915
    ozpropdev wrote: »
    and from instructions_v9.txt - ALIASES
    Ah, I hadn't looked there obviously. Thanks.
  • ozpropdevozpropdev Posts: 2,792
    evanh wrote: »
    One question is: What would happen if the video driver was somehow being loaded into Cog #1 instead of, I presume, Cog#0? Would the COGATN#1 interfere with those Streamer events?

    What will the other Cog do if it never receives it's attention event?
    With the current FPGA images that support the DAC's they are only accessable from Cog #0.
    In the above code the COGATN is only half of the attention mechanism.
    I hadn't got to the fun part of polling it yet from another cog. :)


  • evanhevanh Posts: 15,915
    ozpropdev wrote: »
    With the current FPGA images that support the DAC's they are only accessable from Cog #0.
    Ah, that's a real possible answer then! If it ain't in Cog #0 then there's not going to be any video.
  • evanhevanh Posts: 15,915
    Oh, but this misfiring of Cogs only randomly occurs if your program is regularly setting that attention event of Cog #1.

    Next question is: What happens if that event is set more often? Does the chance of the wrong Cog being loaded also occur more often?
  • ozpropdevozpropdev Posts: 2,792
    evanh wrote: »
    ozpropdev wrote: »
    With the current FPGA images that support the DAC's they are only accessable from Cog #0.
    Ah, that's a real possible answer then! If it ain't in Cog #0 then there's not going to be any video.
    The video driver in this case is always Cog #0 as it's the primary initiating code.
    It never is loaded anywhere else.


  • ozpropdevozpropdev Posts: 2,792
    edited 2016-06-03 14:44
    Chip
    The code appears to hang at the COGATN instruction which explains the no video output symptom.

    I think the issue is a conflict between the interrupt driven video driver and COGATN.
    If I modify the driver to run without interrupts the code runs fine and COGATN works nicely.

  • SeairthSeairth Posts: 2,474
    @ozpropdev,

    Change the line to COGATN #%10 instead and see if that works. As you have it now, the cog is setting its own ATN flag.
  • rjo__rjo__ Posts: 2,114
    edited 2016-06-03 15:22
    COGATN doesn't hang in my code. Must have something to do with interrupt services... I don't explicitly use them. P123-A9.
  • rjo__rjo__ Posts: 2,114
    Brian,

    When I put cogatn into Chip's ntsc_256_interrupt.spin inside the field loop, it seems fine: 10 out of 10.
    I'm not setup for VGA right now. Try substituting a nop for your cogatn and leave the interrupts as they were... timing issue?
  • rjo__rjo__ Posts: 2,114
    edited 2016-06-03 16:14
    While we are on the subject... is there a register that reflects the current value set by cogatn at the system level?
  • SeairthSeairth Posts: 2,474
    rjo__ wrote: »
    While we are on the subject... is there a register that reflects the current value set by cogatn at the system level?

    No. All a cog sees is the event that's set by the logical-or of the associated COGATN bit from all of the other cogs (including itself, I'm guessing).
  • rjo__rjo__ Posts: 2,114
    thanks
  • cgraceycgracey Posts: 14,152
    The COGATN pulse lasts only one clock.

    Note that most events/interrupts have been renumbered. Be sure to use the latest documentation.
  • cgraceycgracey Posts: 14,152
    In looking at the code and trying it out, I found the problem:
    xcont   #10,#0                  'do streamer instruction to start interrupt sequence

    ...needs to become something like...
    xcont   #100,#0                 'do streamer instruction to start interrupt sequence

    You were just running out of time to do the first XCONT before the streamer buffer fully emptied, then requiring TWO, not just one, XCONT to carry on the show.
  • jmgjmg Posts: 15,173
    So that works ok on a 2 COG build, because there is less latency ?

    Which raises other questions...

    Why did the code break on the latest build, or was it just noticed on the latest build ?

    Why is there this effect " it failed 5 times in 20 downloads." ?

    Is reset exit not always the same ? - ie can something download does, vary how P2 exists from reset ?
  • cgraceycgracey Posts: 14,152
    jmg wrote: »
    So that works ok on a 2 COG build, because there is less latency ?

    Which raises other questions...

    Why did the code break on the latest build, or was it just noticed on the latest build ?

    Why is there this effect " it failed 5 times in 20 downloads." ?

    Is reset exit not always the same ? - ie can something download does, vary how P2 exists from reset ?

    It was right on the edge. If you change that #10 to #9, it fails every time. Lower-slice versions have lower latency which get them into the safe zone, in the case of this software example. The reason there is any uncertainty, at all, is probably due to serial receiving in relation to the egg beater. There is no bug here, just software cutting timing too close.
  • jmgjmg Posts: 15,173
    cgracey wrote: »
    ... The reason there is any uncertainty, at all, is probably due to serial receiving in relation to the egg beater...

    I wonder how that " it failed 5 times in 20 downloads" varies over many resets, of the same download ?

    Ideally, you want every reset exit to be the same, and to have no dice effects, as bugs that (eg) vary with download, but not reset, are much harder to find.


Sign In or Register to comment.