COGATN causes erratic Pnut F11 download behaviour

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?
«1

Comments

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

    Thanks for conveying this problem.
  • 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.

  • 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).
  • No video output is the symptom, yet green led blinks every time.
    Fails ~1 in 5 downloads.


  • Oz,
    What is the RESI1 instruction?
  • 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?)


  • The next instruction after the RESI? ... so it's an event based task scheduler? That's a scary simple!
  • I think it's missing from the docs.
  • 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
    


  • 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?
  • ozpropdev wrote: »
    and from instructions_v9.txt - ALIASES
    Ah, I hadn't looked there obviously. Thanks.
  • 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. :)


  • 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.
  • 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?
  • 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,742
    edited 2016-06-03 - 14:44:26
    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.

  • @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,115
    edited 2016-06-03 - 15:22:18
    COGATN doesn't hang in my code. Must have something to do with interrupt services... I don't explicitly use them. P123-A9.
  • 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,115
    edited 2016-06-03 - 16:14:00
    While we are on the subject... is there a register that reflects the current value set by cogatn at the system level?
  • 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).
  • thanks
  • The COGATN pulse lasts only one clock.

    Note that most events/interrupts have been renumbered. Be sure to use the latest documentation.
  • 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: 14,567
    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 ?
  • 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: 14,567
    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.