COGATN causes erratic Pnut F11 download behaviour

2»

Comments

  • evanhevanh Posts: 10,229
    edited 2016-06-03 - 23:20:30
    JMG,
    It'll be a dice roll on the HubRAM rotation latencies. EDIT: Although, I do note the RDLONG 0,ptrb there at line 38, it should make things consistent ...
  • cgraceycgracey Posts: 13,176
    edited 2016-06-03 - 23:25:38
    jmg wrote: »
    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.


    There is a PC involved here which is sending serial to the Prop2. That is where the timing uncertainty is coming from. If we were booting from a Flash, there would be no source of uncertainty.
  • Seairth wrote: »
    @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.
    The COGATN value doesn't change the symptom at all.
    It doesn't seem to matter if the cog tries to ATN itself. :)

  • cgracey wrote: »
    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.

    Thanks Chip!
    That did the trick.

    This highlights that for OBEX2 we might have to split of code for all the different variants.
    As demonstrated here, code that runs on one P2 variant may not work properly on another.

  • I wouldn't mind knowing a bit more detail about what is failing to trigger.
  • ozpropdev wrote: »
    Seairth wrote: »
    @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.
    The COGATN value doesn't change the symptom at all.
    It doesn't seem to matter if the cog tries to ATN itself. :)

    You could use a NOP instead of COGATN and the results are the same. It's a case of timing being cut too close. Just increase the XINIT #10 to #100 and you'll have a lot more head room.
  • cgracey wrote: »
    You could use a NOP instead of COGATN and the results are the same. It's a case of timing being cut too close. Just increase the XINIT #10 to #100 and you'll have a lot more head room.
    By increasing the value from #10 to #11 is enough to solve the timing issue.

    I like to live on the edge but that was a bit too close :lol:

    P.S. Apologies to the COGATN instruction for my finger pointing.

  • ozpropdev wrote: »
    cgracey wrote: »
    You could use a NOP instead of COGATN and the results are the same. It's a case of timing being cut too close. Just increase the XINIT #10 to #100 and you'll have a lot more head room.
    By increasing the value from #10 to #11 is enough to solve the timing issue.

    I like to live on the edge but that was a bit too close :lol:

    P.S. Apologies to the COGATN instruction for my finger pointing.

    I would make it large, just to be safe, and to allow you more time, in case you added some more instructions.
  • ozpropdev wrote: »
    This highlights that for OBEX2 we might have to split of code for all the different variants.
    As demonstrated here, code that runs on one P2 variant may not work properly on another.

    That's not necessary, at all. Just don't cut your timing so close, then one size fits all. Maybe it would be good policy to design software on the 16-cog version, just to avoid these possibilities. Better yet, just be aware of what is happening, time wise, and avoid the whole potentiality.
  • cgracey wrote: »
    I would make it large, just to be safe, and to allow you more time, in case you added some more instructions.
    No worries Chip, done. :)

  • jmgjmg Posts: 14,567
    ozpropdev wrote: »
    This highlights that for OBEX2 we might have to split of code for all the different variants.
    As demonstrated here, code that runs on one P2 variant may not work properly on another.
    There may be some HUB-sync cases where that can happen, but they should be rare.

    I'm more curious about why this did not always work ?
    ozpropdev wrote: »
    By increasing the value from #10 to #11 is enough to solve the timing issue.
    When this is in Download -> fail-mode, is it always failing, on every reset, until a fresh Download rolls the dice again ?

  • Roy ElthamRoy Eltham Posts: 2,950
    edited 2016-06-04 - 03:36:42
    jmg,
    You can't reset and have your P2 PASM code loaded without downloading it again. There's no flash/eeprom on the P2 FPGA emulation setup (at least that I am aware of), even if there is something on the board for it, the P2 ROM doesn't have anything setup to save it off to flash/eeprom and then boot from their on reset yet.
  • jmgjmg Posts: 14,567
    edited 2016-06-04 - 03:57:17
    Roy Eltham wrote: »
    jmg,
    You can't reset and have your P2 PASM code loaded without downloading it again. There's no flash/eeprom on the P2 FPGA emulation setup (at least that I am aware of), even if there is something on the board for it, the P2 ROM doesn't have anything setup to save it off to flash/eeprom and then boot from their on reset yet.
    OK, I'll rephrase the question.
    After the hard-reset which launches the boot loader, each COG has an effective soft-reset that executes the first opcode of code inside that COG.

    If that soft-reset step is repeated, is the problem stable from there, or not ?
    cgracey wrote: »
    If we were booting from a Flash, there would be no source of uncertainty.
    Maybe that needs to be proven too. Will that Flash-boot
    a) Always work
    or
    b) Always fail ?

    A system that gives differing debug outcomes, based on download-run debug, vs Flash-start debug, seems less than ideal to me ?

  • @jmg
    When a download was successful the code worked as expected with no issues.
  • cgraceycgracey Posts: 13,176
    edited 2016-06-04 - 04:46:41
    Jmg, you are right!!!!

    I wasn't getting the fact that when the cog loads itself, its hub relationship is deterministic at the start of the program.

    I realize what the problem is now. When an XCONT is used to start the streamer, as opposed to an XINIT, there is some variability, based on what the streamer was doing before. The streamer should be cold started by giving a command via XINIT, then XCONT can be used set up the next command for when the command given by the XINIT runs out. So, to make this interrupt work, you must do an XINIT to get the streamer started, then do an XCONT to buffer the next command for when the command begun by XINIT finishes. When the command given by the XCONT begins to execute, the 'transfer buffer empty' event will occur.

    I changed the code, between the first and last instruction listed here:
                            loc     adrb,#@current_video_line
    
    			xinit   #11,#0                  'do streamer instruction to start interrupt sequence
    			xcont	#10,#0			'if the #11 and #10 sum to less than 21, it fails!!!
      
                            mov     ijmp1,#field            'set up streamer-empty interrupt
    
                            setint1 #8			'after both XINIT and XCONT, enable the interrupt
    
                            jmp     #game_engine
    

    Now, if D's in the XINIT and XCONT instructions sum to less than 21 this will fail every time. If they sum to 21, or more, it always works.
  • Seairth wrote: »
    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).
    That's right Seairth, a COG can attention itself.
    dat		org
    
    		mov	dirb,##$ffff
    
    		call	#show_status	'led0 = off (reset status)
    
    		cogatn	#1		'attention 'me'
    		call	#show_status	'led1 = on (first attention event)
    
    		call	#show_status	'led2 - off (cleared after last poll)
    
    		cogatn	#1		'attention 'me'
    		call	#show_status	'led3 = on (second attention event)
    
    there		jmp	#there
    
    show_status	pollatn	wc		'get attention status
    		setbc	outb,ax
    		add	ax,#1		'next led
    		ret
    
    ax		long	0
    
    
    This could be useful as a self clearing temporary flag. :)

Sign In or Register to comment.