Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 138 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1135136138140141160

Comments

  • I had a duh moment, I realized I couldn't use ROM Flash on the same pins as SD, so I moved the pull-up/CS to P57 instead and we can still separate SPI data pins. There may be a point to supporting 4-pin mode only in the future but if we always test for 3-pin mode then it means that some designs will be able to use that one extra pin. The thing that concerns me is that with all the pullup options we are introducing caveats for the use of those pins. Since there is no other easy way to do it then maybe we just need to accept that just as P1 reserved 4 pins for booting, that P2 needs 6/7 pins?
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-07 08:49
    Here is what I see as the user connection of Flash and SD.
    For 4pin SPI, the resistor is removed and the flash DO pin is connected to P58.

    The ROM boot will check for a pullup on P61=CS(Flash) to determine if Flash is present.
    The ROM boot will check for a pullup on P60=CS(SD Card internal pullup) to determine if an SD card exists.

    When sending information to the Flash, the ROM boot should check for a reply on both P59 and P58. If the reply is on P59 then its 3-pin mode, or the reply is on P58 then its 4pin mode.

    P2_FLASH_SD.jpg
    528 x 460 - 38K
  • jmgjmg Posts: 15,140
    I had a duh moment, I realized I couldn't use ROM Flash on the same pins as SD, so I moved the pull-up/CS to P57 instead and we can still separate SPI data pins. There may be a point to supporting 4-pin mode only in the future but if we always test for 3-pin mode then it means that some designs will be able to use that one extra pin. The thing that concerns me is that with all the pullup options we are introducing caveats for the use of those pins. Since there is no other easy way to do it then maybe we just need to accept that just as P1 reserved 4 pins for booting, that P2 needs 6/7 pins?

    Keep in mind, with all this pin creep, that you can buy small MCUs now that can boot using just the Serial pins at first, for ~25c, ~21c, with 16-18k of FLASH.
    At one stage there was a single pin boot mode, allows just one pin to be committed.
  • jmg wrote: »
    Keep in mind, with all this pin creep, that you can buy small MCUs now that can boot using just the Serial pins at first, for ~25c, ~21c, with 16-18k of FLASH.
    At one stage there was a single pin boot mode, allows just one pin to be committed.

    You know I love those little support micros, especially since they are just another cheap tiny component these days. In fact they can be smaller and cheaper than the main crystal, but whereas everyone sees a crystal and a regulator as a key component, an extra support micro is a little different. Even though it may be small and cheap, it has to be programmed, somewhere, somehow, sometime. If they were as common and cheap as a 2N2222 and readily and easily available then it could probably be specified as a key component. But there are a lot of crystal and regulator manufacturers and types so that we are not overly dependent upon any one type or source.

    The P1 has slow I2C EEPROM but the advantage there was that it was two wire and it was a bus, so you could add more devices to the same 2 wires. What the world needs is I2C addressing but SPI speeds, which is possible, it's just that they don't do it. What a pity. I always think of start and stop conditions as chip selects and never see a need for multi-master or arbitration or clock stretching, it is unnecessary cruft that get in the way of bus speeds.

    But the P2 can't afford to come into the world already hobbled by the need for a support chip. Sure, hardware designers can use a micro for single pin booting up to 2M serial but there would have to be a good reason to do so and most designs would never need it.
  • Cluso99Cluso99 Posts: 18,066
    Chip,

    I need some help with pnut...

    How do I ensure that a JMP and CALL to a "#label" gets defined as a hub address?
    I presume the use of "#@label" just forces an absolute cog/lut/hub address. "##@label" is invalid.

    The label can also be in cog or lut space due to the code following cog/lut code.

    This is at least one reason why v133a is not working as I have decoded pnut's output.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-07 11:54
    I have removed the pullups from the SD card on the BeMicroCV-A9 but I am still seeing pullups in software on P61 and P59.
    The pullup on P58 has now gone and P60 follows the SD-CSn depending on whether the SD card is inserted or not, as it should.
    A pulldown are now seen on P58. P60 has a pulldown if an SD card is not present.

    The pullup on P59 (source unknown) causes v133a to go direct to serial (bypassing the further tests - which were also wrong)

    The tests for <esc> (TAQOZ) and ctl-D (Monitor) don't work because of the JMP going to cog/lut instead of hub :(

    Overriding P59 with a 10K pulldown does not pull the pin down either.
  • Cluso99 wrote: »
    Chip,

    I need some help with pnut...

    How do I ensure that a JMP and CALL to a "#label" gets defined as a hub address?
    I presume the use of "#@label" just forces an absolute cog/lut/hub address. "##@label" is invalid.

    The label can also be in cog or lut space due to the code following cog/lut code.

    This is at least one reason why v133a is not working as I have decoded pnut's output.

    Cluso
    Ttry using #\
    For immediate-branch and LOC address operands, "#" is used before the
    address. In cases where there is an option between absolute and relative
    addressing, the assembler will choose absolute addressing when the branch
    crosses between cog and hub domains, or relative addressing when the
    branch stays in the same domain. Absolute addressing can be forced by
    following "#" with "\".

  • Cluso99Cluso99 Posts: 18,066
    Ozprop,
    Thanks for that info.
    But how can I enforce Hub?
  • evanhevanh Posts: 15,091
    I certainly got confused about the assembler directives the moment I used a COGINIT. Never did sort it out. I'm guessing this is what Cluso is dealing with too.

  • Cluso99Cluso99 Posts: 18,066
    A little more experimenting...

    JMP/CALL #addr varies depending on code and placement of org/orgh and the label "addr"

    JMP/CALL #@addr seems to always use absolute hub

    JMP/CALL #\addr uses absolute cog or absolute hub, depending on code and placement of org/orgh and the label "addr"

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-07 16:16
    @Cluso - don't forget to add the coginit at address 0 to your test code. It doesn't matter if you leave it in there for the final ROM either as only the hub ROM is used anyway but there is no other way to test when you load it via PNut.
    		orgh 0
    		org 0
    		coginit #0,##_hubROM
    


    BTW - I've decided that I don't really need a second SPI Flash for the test "ROM", I will simply read in 16kB from the SPI Flash. So immediately after the mask ROM is loaded and run it will check if there is a pullup on P58 which assigned to the Flash and SD Dout. If so, it will proceed to overwrite the hub ROM with 16kB from the SPI Flash. This doesn't interfere with and has nothing to do with hub ROM loading user code either. I'm thinking of placing the HUB rom code at the start of $0F.C000 in the SPI Flash since the smallest devices we would use are 8Mbit at least and that also corresponds nicely with the hub ROM address.

    @Chip - when I test out this code perhaps you can incorporate it into FPGA and also make sure to unmap the I/O so that we can attached SD and SPI Flash to the external I/O pins rather than using the internal memory since we have no control of pullups on the pcb. This way we can test with and without pullups etc and also check the timing and sequencing while we are at it.
  • cgraceycgracey Posts: 14,131
    @Cluso - don't forget to add the coginit at address 0 to your test code. It doesn't matter if you leave it in there for the final ROM either as only the hub ROM is used anyway but there is no other way to test when you load it via PNut.
    		orgh 0
    		org 0
    		coginit #0,##_hubROM
    


    BTW - I've decided that I don't really need a second SPI Flash for the test "ROM", I will simply read in 16kB from the SPI Flash. So immediately after the mask ROM is loaded and run it will check if there is a pullup on P58 which assigned to the Flash and SD Dout. If so, it will proceed to overwrite the hub ROM with 16kB from the SPI Flash. This doesn't interfere with and has nothing to do with hub ROM loading user code either. I'm thinking of placing the HUB rom code at the start of $0F.C000 in the SPI Flash since the smallest devices we would use are 8Mbit at least and that also corresponds nicely with the hub ROM address.

    @Chip - when I test out this code perhaps you can incorporate it into FPGA and also make sure to unmap the I/O so that we can attached SD and SPI Flash to the external I/O pins rather than using the internal memory since we have no control of pullups on the pcb. This way we can test with and without pullups etc and also check the timing and sequencing while we are at it.

    I think all this can be done by using the FPGA version I posted that allows the ROM to be overwritten. Just change the software to use the lower pins, for now, instead of P61..P58.
  • cgraceycgracey Posts: 14,131
    Peter, Cluso,

    I will switch my ROM code to use the 4-wire setup for SPI.

    This is how I would like the pull-up options to be. Does this look okay to you guys?
    	Serial
        +----------------
    P63 |	RX
    P62 |	TX
    
    
    	SPI	SD
         +---------------
    P61  |	CSn	CLK
    P60  |	CLK	CSn
    P59  |	DI	DI
    P58  |	DO	DO
    
    
    				P61	P60
    				-----------
    serial				!up	!up
    serial window + SD		!up	 up
    serial window + SPI		 up	!up
    SPI or serial if SPI error	 up	 up
    
  • jmgjmg Posts: 15,140
    edited 2018-05-07 20:18
    I had a duh moment, I realized I couldn't use ROM Flash on the same pins as SD, so I moved the pull-up/CS to P57 instead and we can still separate SPI data pins. There may be a point to supporting 4-pin mode only in the future but if we always test for 3-pin mode then it means that some designs will be able to use that one extra pin. The thing that concerns me is that with all the pullup options we are introducing caveats for the use of those pins. Since there is no other easy way to do it then maybe we just need to accept that just as P1 reserved 4 pins for booting, that P2 needs 6/7 pins?

    Another approach to reduce affected pins, is to have a resistor between pins also convey user config information.
    That's a common trick in i2c address expansion, where they want to get more info encoded into fewer pins.

  • jmgjmg Posts: 15,140
    edited 2018-05-08 00:35
    cgracey wrote: »
    I will switch my ROM code to use the 4-wire setup for SPI.
    Sounds good.
    cgracey wrote: »
    This is how I would like the pull-up options to be. Does this look okay to you guys?

    A variant on that using pin-to-pin resistors, would be this (below). The advantage here, is P60 is now undisturbed for UART boot cases. Only P61 needs to be tested, reducing the impact

    The other 3 choices are still covered, and 2 pins are disturbed only once you know you need to use SD/SPI.
    	Serial
        +----------------
    P63 |	RX
    P62 |	TX
    
    
    	SPI	SD
         +---------------
    P61  |	CSn	CLK
    P60  |	CLK	CSn
    P59  |	DI	DI
    P58  |	DO	DO
    
    				P61	P60  
    				-------------
    serial				!up	xx    P61 floating is Serial, P60 is untouched for serial boot.
    serial window + SD		 up	 up
    serial window + SPI		 up	R-P61  R between P60 & P61 gives another signal case.
    SPI or serial if SPI error	 up	 !up
    

  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-07 22:52
    cgracey wrote: »
    Peter, Cluso,

    I will switch my ROM code to use the 4-wire setup for SPI.

    This is how I would like the pull-up options to be. Does this look okay to you guys?
    	Serial
        +----------------
    P63 |	RX
    P62 |	TX
    
    
    	SPI	SD
         +---------------
    P61  |	CSn	CLK
    P60  |	CLK	CSn
    P59  |	DI	DI
    P58  |	DO	DO
    
    
    				P61	P60
    				-----------
    serial				!up	!up
    serial window + SD		!up	 up
    serial window + SPI		 up	!up
    SPI or serial if SPI error	 up	 up
    
    No Chip.
    P60's pull-up is not a physical pull-up but rather the internal pull-up inside the SD Card.

    Perhaps we can have a chat. I will put up Skype in about 1/2 hr if you are available. Not sure about Peter as he is not at home but will have his laptop with him. I'll call him.

    Postedit
    Just read your other post Chip where you will be at your mum's so let's wait till Thursday for that call.
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    No Chip.
    P60's pull-up is not a physical pull-up but rather the internal pull-up inside the SD Card.
    I'm not clear why that matters ? - the code does not care if it is on the PCB, or inside the SD ?
    It does matter that the sense chosen, of pullup, matches what the SD actually does - which it seems to do just fine ?


  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-08 00:10
    Chip,
    This is the way I see it
           SERIAL
        +----------------
    P63 |   RX
    P62 |   TX
    
           FLASH    SD
         +---------------
    P61  |  CSn     CLK
    P60  |  CLK     CSn
    P59  |  DI      DI     MOSI
    P58  |  DO      DO     MISO
    
    P61     P60                                      
    -----------                                      
    !up     !up      SERIAL                          
     x       up      SD    then SERIAL if SD error             
     up     !up      FLASH then SERIAL if FLASH error             
    

    My reasoning...

    Professional users want the fastest boot time, and they will be using either Flash, SD or both.

    The SD card can (normally) be removed. The argument saying it cannot be removed is the same as Flash cannot be removed - it isn't relevant.

    SD should take preference over FLASH. Why - because it can be removed, causing Flash or serial to be used instead. And SD can have the program updated on the SD externally.

    For download development, either don't fit FLASH/SD or override P61 pull-up with stronger pull-down, and remove SD. We will need you to test the timing and values with the shuttle chip please.

    Other option...

    Run SERIAL in parallel on a second cog, and if/when the "> " autobaud sequence is seen, terminate the SD/FLASH cog.

    Or, have P59 pull-up force SERIAL (disregarding P60 & P61 pull-ups)

    3-pin FLASH...

    I have no problem with supporting 3-pin as long as 4-pin is also supported. It is quite easy to test for a reply on both P58 & P59 and determine which mode is being used for subsequent replies.
  • cgraceycgracey Posts: 14,131
    Cluso, that would complicate downloading to RAM vs flash. It would necessitate a switch or a jumper.

    Does anyone know if it's possible to change the PC-side DTR line output state without interrupting the data stream being transmitted by the PC? How about on a Mac or a Chromebook? I'm thinking about getting around needing a serial timing window.
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    cgracey wrote: »
    Peter, Cluso,

    I will switch my ROM code to use the 4-wire setup for SPI.

    This is how I would like the pull-up options to be. Does this look okay to you guys?
    	Serial
        +----------------
    P63 |	RX
    P62 |	TX
    
    
    	SPI	SD
         +---------------
    P61  |	CSn	CLK
    P60  |	CLK	CSn
    P59  |	DI	DI
    P58  |	DO	DO
    
    
    				P61	P60
    				-----------
    serial				!up	!up
    serial window + SD		!up	 up
    serial window + SPI		 up	!up
    SPI or serial if SPI error	 up	 up
    
    No Chip.
    P60's pull-up is not a physical pull-up but rather the internal pull-up inside the SD Card.

    Perhaps we can have a chat. I will put up Skype in about 1/2 hr if you are available. Not sure about Peter as he is not at home but will have his laptop with him. I'll call him.

    Postedit
    Just read your other post Chip where you will be at your mum's so let's wait till Thursday for that call.

    Aside from CSn, does an SD card introduce any other pull-ups?
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso, that would complicate downloading to RAM vs flash. It would necessitate a switch or a jumper.

    Does anyone know if it's possible to change the PC-side DTR line output state without interrupting the data stream being transmitted by the PC? How about on a Mac or a Chromebook? I'm thinking about getting around needing a serial timing window.
    There are trade-offs here. What is the prime target? Hobbyist downloading or development vs commercial production?
    It's easy enough to program the flash with a non-compliant checksum to force skipping the flash, making serial come up quicker.

    The alternative is to run serial in a second cog and terminate the sd/flash download by cogstop.

    As for DTR, there are enough problems with PC's etc now with serial. But you are never going to get accurate timing on DTR because the OS will be in the way.
    cgracey wrote: »
    Aside from CSn, does an SD card introduce any other pull-ups?
    No, the card itself only pulls CS high, provided of course the hw designer doesn't go putting resistors on all pins :(


  • jmgjmg Posts: 15,140
    edited 2018-05-08 07:14
    cgracey wrote: »
    Does anyone know if it's possible to change the PC-side DTR line output state without interrupting the data stream being transmitted by the PC? How about on a Mac or a Chromebook? I'm thinking about getting around needing a serial timing window.

    Depends what 'interrupting' means - it is very hard to ensure the DTR has exact character timing, but that can be improved by reading after writing, which I think uses another USB frame (so adds 1ms) and I've not tested it with varying buffer depths...

    Some delay will always be present as P2 exits reset, but you can send a continually repeating _Chk string, and Autobaud from that.
    ie you can toggle DTR to pulse reset and immediately start TX, and it does not matter what exact timing of DTR/CHAR is, or which (partial) frame the P2 comes out of reset on. The HW Autobaud is strict enough to trigger only on the first whole ">".

    That continual send is what a host MCU would do, in order to get the fastest possible boot time.


  • Cluso99Cluso99 Posts: 18,066
    Hey Chip,
    Peter & I both think the use of zerox is wrong here. Could you confirm please?
    '+-----------------------------------------------------------------------------+
    '+ Reset smart pins                                                            +
    '+-----------------------------------------------------------------------------+
    reset_pins      setint1 #0                      'disable int1
    
                    mov     dira,#0                 'reset smart pins (avoids output on mode clears)
                    ''zerox   dirb,#30		'' what were you thinking?
                    decod   dirb,#(tx_pin-32)
    
                    wrpin   #0,#rx_ths              'clear rx_ths mode
                    wrpin   #0,#rx_tne              'clear rx_tne mode
                    wrpin   #0,#rx_pin              'clear rx_pin mode
            _ret_   wrpin   #0,#tx_pin              'clear tx_pin mode
    
    lut_end
    
  • I believe it should be
    	zerox	dirb,#29	
    
    to reset P63,P62

  • Cluso99Cluso99 Posts: 18,066
    We were thinking the clear applied to all pins except P62.
    The intent is not clear though.
  • ZEROX Zero extends D above bit S[4:0].
    Basically Chip is doing a single instruction AND dirb,##3fffffff
  • Cluso99 wrote: »
    The intent is not clear though.
    This would reset the 4 associated serial pins without disturbing the SPI pins.

  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-08 11:13
    We know what xerox is doing but we question that operation. Look at the preceding instruction. Together, they imply all bits other than P62 should be zeroed.

    Otherwise a DIRH #63 would have been more appropriate.
  • That operation clears only one bit:
    TAQOZ# -1 3 ZEROX .LONG 0000.000F ok
    TAQOZ# -1 30 ZEROX .LONG 7FFF.FFFF ok
    

    This instruction clears all other dir bits except the txd pin.
    decod   dirb,#(tx_pin-32)
    
  • Cluso99 wrote: »
    We know what xerox is doing but we question that operation. Look at the preceding instruction. Together, they imply all bits other than P62 should be zeroed.

    Otherwise a DIRH #63 would have been more appropriate.
    I still believe the ZEROX instruction should be #29 not #30.
    Yes, the DECODE instruction doesn't seem to belong.
    A DRVH #62 for idle state would make more sense.

Sign In or Register to comment.