Prop2 FPGA files!!! - Updated 16 October 2017 - Version 24a

18788909293

Comments

  • Garryj's USB code works with low speed keyboard and mouse with V23a
    Prop Info and Apps: http://www.rayslogic.com/
  • Chip
    All V23a images loaded Ok. :cool:

    I ran some test code for the debug interrupt with the new vector changes.
    All the multi-cog variants work ok but I experienced different behavour from the single cog variants.

    Here's a snippet of my code
    		wrlong	isr,##$FFFFC - (test_cog * 4)	'set isr address
    		coginit	#test_cog,##@code_2_debug	'launch cog with code to be tested
    		nop					'??? needed for single cog versions ???
    		cogstop	#0				'stop start up cog
    
    
    What I have found is that I need to add a dummy instruction after the coginit for the single cog versions.
    Without the nop the following cogstop is executed before the cognit fires.
    Normally if the selected cog is 0 it never reaches the cogstop instruction.

    It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
    :)



    Melbourne, Australia
  • My XORO32 and SUBS/CMPS testers work correctly.
  • ozpropdev wrote: »
    Chip
    All V23a images loaded Ok. :cool:

    I ran some test code for the debug interrupt with the new vector changes.
    All the multi-cog variants work ok but I experienced different behavour from the single cog variants.

    Here's a snippet of my code
    		wrlong	isr,##$FFFFC - (test_cog * 4)	'set isr address
    		coginit	#test_cog,##@code_2_debug	'launch cog with code to be tested
    		nop					'??? needed for single cog versions ???
    		cogstop	#0				'stop start up cog
    
    
    What I have found is that I need to add a dummy instruction after the coginit for the single cog versions.
    Without the nop the following cogstop is executed before the cognit fires.
    Normally if the selected cog is 0 it never reaches the cogstop instruction.

    It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
    :)



    It is a GOOD thing you found this!!!

    I was worried that something like this could be lurking when the hub can receive an instruction EVERY clock, even though instructions take two clocks.

    If I recall, COGINIT first disables the cog to reset it, then enables the cog to start it. I think the enabling and COGSTOP are collIding and the COGSTOP takes priority. I'll fix this.

    Meanwhile, could you please confirm that adding a WC after the COGINIT operands makes the problem go away? That should have the effect of adding two clock cycles to the COGINIT, causing ample separation from the COGSTOP.
  • evanh wrote: »
    My XORO32 and SUBS/CMPS testers work correctly.

    Super. Thanks.
  • evanhevanh Posts: 4,180
    edited October 12 Vote Up0Vote Down
    ozpropdev wrote: »
    It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
    :)
    It's probably wise to fix it while it's freshly noted but that's probably the only reason. I can't imagine a real single Cog Prop coming off the production lines!

    Come to think of it, what is that coding trying to do? It's like a soft reset or something.
  • cgracey wrote: »
    Meanwhile, could you please confirm that adding a WC after the COGINIT operands makes the problem go away? That should have the effect of adding two clock cycles to the COGINIT, causing ample separation from the COGSTOP.

    Yes
    Adding the WC fixes the problem.


    Melbourne, Australia
  • evanh wrote: »
    Come to think of it, what is that coding trying to do? It's like a soft reset or something.
    Debug interrupts cannot be started from within a running cog.
    Its has to be configured before launch.



    Melbourne, Australia
  • ozpropdev wrote: »
    Chip
    All V23a images loaded Ok. :cool:

    I ran some test code for the debug interrupt with the new vector changes.
    All the multi-cog variants work ok but I experienced different behavour from the single cog variants.

    Here's a snippet of my code
    		wrlong	isr,##$FFFFC - (test_cog * 4)	'set isr address
    		coginit	#test_cog,##@code_2_debug	'launch cog with code to be tested
    		nop					'??? needed for single cog versions ???
    		cogstop	#0				'stop start up cog
    
    
    What I have found is that I need to add a dummy instruction after the coginit for the single cog versions.
    Without the nop the following cogstop is executed before the cognit fires.
    Normally if the selected cog is 0 it never reaches the cogstop instruction.

    It's not a big deal but I thought i'd mention it just in case it indicates a possible issue for the silicon.
    :)



    Ozpropdev,

    It took me a while to get this straightened out. I'm recompiling everything now, as this involved some changes to the hub logic. I'm sure glad you found this!

    I should have a new set of files out tomorrow. Thanks!
  • A new version 24 is posted at the top of this thread.

    This version 24 fixes the COGINIT+COGSTOP collision that was occurring on single-cog FPGA images.

    Please try this out and test your code base with it. Thank you!
  • Chip
    All the single cog variants work fine now.

    All but the BeMicro-A9 image work Ok.
    The BeMicro-A9 image identifies Ok with Pnut but doesn't load any code via F11.
    Melbourne, Australia
  • ozpropdev wrote: »
    Chip
    All the single cog variants work fine now.

    All but the BeMicro-A9 image work Ok.
    The BeMicro-A9 image identifies Ok with Pnut but doesn't load any code via F11.

    Ok. Thanks. I'll fix it.
  • cgraceycgracey Posts: 8,030
    edited October 16 Vote Up0Vote Down
    Ozpropdev,

    I recompiled the BeMicro-A9 image from scratch, but it wound up identical to the image contained in the v24 release. So, there wouldn't be any difference.

    It's very puzzling that it identifies, but doesn't run code. The only thing I can imagine is that maybe the clock generation is off from 80MHz. It uses the same PLL file as the the Prop123-A9, though, which has always worked.

    I will keep thinking about this, but I don't know what to do. I don't have a BeMicro-A9, myself.
  • evanhevanh Posts: 4,180
    edited October 16 Vote Up0Vote Down
    Oz,
    Try using Dave's loadp2 to do the transfer instead of PNut. There is config options in the latest version of loadp2 for matching the clock rates. Latest - http://forums.parallax.com/discussion/comment/1416789/#Comment_1416789

    EDIT: Also, loadp2 has different handling of the comport control lines.
  • cgraceycgracey Posts: 8,030
    edited October 16 Vote Up0Vote Down
    Ozpropdev,

    I did notice one thing...

    The BeMicro-A9 image would soft reset when D[8] of 'CLKSET {#}D' was high, whereas the Prop123-A9 image would reset when D[25] was high, which was correct. I've updated all the images to use D[25] as a soft reset for 'CLKSET {#}D'. Could this be causing the behavioral difference you're seeing?

    I'm recompiling the BeMicro-A9 image now to use D[25] as soft reset, instead of the errant D[8]. I don't know if this will make any practical difference for anybody, yet, though.
  • Chip
    Pnut reports "Hardware lost on COM7" but can ID P2 Ok with Ctrl-G.
    I can however load code with Daves loadp2 program fine @3Mbaud. (Thanks for the suggestion @evanh!)
    Weird huh?

    Melbourne, Australia
  • Yay! That proves the FPGA image is fine.
  • cgraceycgracey Posts: 8,030
    edited October 16 Vote Up0Vote Down
    evanh wrote: »
    Yay! That proves the FPGA image is fine.

    But why in the world doesn't PNut.exe work with it? It's all crystal/PLL-based, anyway. Same as the Prop123-A9.
  • evanhevanh Posts: 4,180
    edited October 16 Vote Up0Vote Down
    Well, since you asked, and I don't have a solid explanation, but I've been bothered by PNut's comms stability since I got my Prop123 board. Ie: I can't use PNut for my Prop123-A9 board. The data flow is precise and complete but the handshaking is wacky. In particular, the Prop gets a physical reset pulse just when the main binary transmit starts. From memory, it's the third of three resets that occur during the whole process after pressing F11.
  • evanh wrote: »
    Well, since you asked, and I don't have a solid explanation, but I've been bothered by PNut's comms stability since I got my Prop123 board. Ie: I can't use PNut for my Prop123-A9 board. The data flow is precise sand complete but the handshaking is wacky.

    I will look into the comm code in PNut, but what makes no sense is that the Prop123-A9 works, while the BeMicro-A9 doesn't.
  • Yep, no sense at all.
    Pnut works fine with all the boards and has done for quite some time.
    Same cables and all.
    I've never had to use anything else but Pnut.
    Melbourne, Australia
  • I just jumped back to V23 to check and Pnut v23 works fine with the Be-A9 board.
    Hmmm.
    Melbourne, Australia
  • Lol, bazaar, but does fit with prior experience.
  • @Dave Hein
    I'm curious, what baud rate does loadp2 run at?
    Melbourne, Australia
  • evanhevanh Posts: 4,180
    edited October 16 Vote Up0Vote Down
    I think there is two parts. First is at 2Mb/s then second part defaults to 115k2. This will be same for PNut.

    EDIT: Err, MainLoader.spin2 says 256kb/s for first part.


    EDIT2: Wrong again, there is LOADER_BAUD for the whole thing. It is 2Mb/s. The user_baud is only for runtime debug strings.
  • evanhevanh Posts: 4,180
    edited October 16 Vote Up0Vote Down
    Ah, Dave has modified Chip's MainLoader source to precalculate from a couple of constants whereas Chip has hand coded numbers in a few places. Chip's one does say 2Mb/s too.

    EDIT: There's no diff in the source between v23 and v24 MainLoader.spin2 from Chip.
  • I am worried that this could indicate some latent problem in the design.
  • cgracey wrote: »
    I am worried that this could indicate some latent problem in the design.
    Yikes! I hope not.
    I tried Pnut on two more machines(laptops) and got the same results.

    Sorry Chip! You must cringe every time you see me post spmething..
    Melbourne, Australia
  • cgraceycgracey Posts: 8,030
    edited October 16 Vote Up0Vote Down
    Ozpropdev, could you check to see if the RESn and RX lines are pulled high on the BeMicro-A9 board?
Sign In or Register to comment.