Shop OBEX P1 Docs P2 Docs Learn Events
P2 SD BOOT ROM v2 (for P2 respin Feb 2019) +exFAT trial - Page 6 — Parallax Forums

P2 SD BOOT ROM v2 (for P2 respin Feb 2019) +exFAT trial

12346

Comments

  • Cluso99Cluso99 Posts: 18,066
    Thanks Lachlan & Brian.
    I'll see if I can reproduce this.
    We found that the SD card (old ROM) was not releasing the DO pin. Hopefully I fixed this in the new ROM (should be in 0002h).
    I wonder if the same problem exists in the Flash not releasing its DO ???

    BTW I have
    SanDisk Ultra 64GB SDXC I U1 C10 A1 red & grey formatted exFAT
    SanDisk Ultra 16GB SDHC I C10 A1
    and some smaller black SanDisk 1GB, 2GB, 8GB
    and some other brands including
    MIXZA 8GB SDHC I U1
    OV 64GB SDXC U1 C10
  • cgracey wrote: »
    After P2+ comes out, with only 120 chips out in the world, tools can focus exclusively on P2+. We'll have a few months of crossover time.
    Unfortunately, many of us have paid $150 for the current boards. It would be nice if they continued to work.

  • TubularTubular Posts: 4,620
    edited 2019-02-21 01:48
    Addendum: The Samsung card ends up in 'serial' - so from there I can
    '> ESC' to Taqoz 1 from P2ES ROM,
    '> ^D' to P2 Monitor

    These are reachable regardless of whether Flash is on or off.

    We seem to have lost the ability to go from Taqoz 2 to Monitor 2h (control D doesn't do it)

    I didn't realize it was in serial because everything looks dead (no led activity etc). Sorry!
  • David Betz wrote: »
    cgracey wrote: »
    After P2+ comes out, with only 120 chips out in the world, tools can focus exclusively on P2+. We'll have a few months of crossover time.
    Unfortunately, many of us have paid $150 for the current boards. It would be nice if they continued to work.

    True, yet many of us paid way way more than that on FPGA boards etc and while they "continue to work", we won't need them and were happy to pay the price to have a leg in on the development and testing of the P2. I would think then that $150 was a very small price to pay. Perhaps you can sell it on eBay for twice that as a "collectors" piece.
  • David Betz wrote: »
    cgracey wrote: »
    After P2+ comes out, with only 120 chips out in the world, tools can focus exclusively on P2+. We'll have a few months of crossover time.
    Unfortunately, many of us have paid $150 for the current boards. It would be nice if they continued to work.

    True, yet many of us paid way way more than that on FPGA boards etc and while they "continue to work", we won't need them and were happy to pay the price to have a leg in on the development and testing of the P2. I would think then that $150 was a very small price to pay. Perhaps you can sell it on eBay for twice that as a "collectors" piece.
    Yup. I bought the FPGA board too.
  • Cluso99Cluso99 Posts: 18,066
    Tubular wrote: »
    Addendum: The Samsung card ends up in 'serial' - so from there I can
    '> ESC' to Taqoz 1 from P2ES ROM,
    '> ^D' to P2 Monitor

    These are reachable regardless of whether Flash is on or off.

    We seem to have lost the ability to go from Taqoz 2 to Monitor 2h (control D doesn't do it)

    I didn't realize it was in serial because everything looks dead (no led activity etc). Sorry!

    OK. Then "> ctl-D" goes to the monitor.

    Can you then try "R_BOOT_P2.BIX"<enter> to see if it will reload the boot file please?
    Note there is no space between "R" and the filename (8.3) which can be any file (including not found ones). The filename is case sensitive!!
    If you substitute "L" for "R" the filename will be loaded but not run, and returns to the monitor with either "=" for success or "!" for failed/not found.
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-21 03:37
    For the most part the v32 instructions are a subset of the v33 instructions. If the larger offsets for the PTRx registers aren't used, and the PTRx registers aren't used for the RDLUT and WRLUT the v33 non-smartpin should encode and work the same as v32.

    I think there will have to be a small change in the PTRx encoding when using a negative offset, and not incrementing or decrementing. I'm not sure how much the BITx instructions have change, but I hope they're the same if SETQ/SETQ2 is not used. It seems like it feasible to generate a v32 binary that could also run on a v33 P2.

    A v32 flag can be added to the assemblers, and they could generate an error if a v33 extension is encountered. I don't see why the current P2 Eval board couldn't be supported for many years.
  • Cluso99 wrote: »
    Thanks Lachlan & Brian.
    I'll see if I can reproduce this.
    We found that the SD card (old ROM) was not releasing the DO pin. Hopefully I fixed this in the new ROM (should be in 0002h).
    I wonder if the same problem exists in the Flash not releasing its DO ???

    Yes it looks like the same problem of SD card not releasing P58 (MISO).

    Its not the flash because we can switch its enable off so it is out of the picture

    We have also sent through a dozen or two extra P60 clock transitions from Taqoz 2, but it still doesn't release the P58 pin. In fact the P58 pin seems to follow the voltage on the P60 pin as we clock it

    Also we can watch with the multimeter - 'float' shows up as 1.65v in highZ mode - separate to hi 3v3 and lo 0v.

    Finally, when we physically remove the card, the SO line (P58) goes to the floating voltage of 1.65v.

  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-21 04:16
    Tubular wrote: »
    Cluso99 wrote: »
    Thanks Lachlan & Brian.
    I'll see if I can reproduce this.
    We found that the SD card (old ROM) was not releasing the DO pin. Hopefully I fixed this in the new ROM (should be in 0002h).
    I wonder if the same problem exists in the Flash not releasing its DO ???

    Yes it looks like the same problem of SD card not releasing P58 (MISO).

    Its not the flash because we can switch its enable off so it is out of the picture
    Not necessarily. This is originally what we thought with the SD, but bringing SD-CS=1 does not always release the SD from driving the DO pin.

    Tho it does seem that I may still have a problem of not releasing DO properly from all exit/abort cases.

    We have also sent through a dozen or two extra P60 clock transitions from Taqoz 2, but it still doesn't release the P58 pin. In fact the P58 pin seems to follow the voltage on the P60 pin as we clock it
    The SD requires the clocking to be on P61, not P60. It is still weird tho. The clocking is supposed to be with SD-CS=1 tho you could try both ways.
    Also we can watch with the multimeter - 'float' shows up as 1.65v in highZ mode - separate to hi 3v3 and lo 0v.
    Finally, when we physically remove the card, the SO line (P58) goes to the floating voltage of 1.65v.
    So it really seems that there is a lock-up problem somewhere on the SD card.
    But it seems from what you are saying, it is only a problem when the Flash is invoked. Perhaps its a problem that the SD card is getting into a lockup because of accessing the Flash ???

    Maybe we may not be able to get both Flash & SD to co-exist with access to both, only co-exist with either or ???
  • Its not just a problem with Flash, on the Samsung card not releasing MISO (DO) also prevents subsequent boot from same SD card

    I think it points to SD rather than Flash, because when I physically remove the SD card, P58 goes to 'float' voltage of 1.65V. The Flash chip is still there and powered

    The 'release' mechanism you tested with Sandisk - can you describe what you did to get the card to release? Was it just pulsing P61 or is there more to it?

  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-21 22:10
    This is the subroutine, and it calls the normal send/receive routine to output $FF
    '+-----------------------------------------------------------------------------+                        \ {{ tweek }}
    '+      /CS=1, Release SD Card DO pin, tristate SD CS/CK/DI/DO                 +                        |
    '+-----------------------------------------------------------------------------+                        |
    _releaseDO      outh    #sd_cs                          ' /CS=1                                         |
                    call    #@_sendFF                       ' 8 CLKs                                        |
                    andn    dirb,             ##($F<<26)    ' tristate CS/CK/DI/DO                          |
                    ret                                 wcz ' restore flags                                 |
    '+=============================================================================+                        /
    
    '+-----------------------------------------------------------------------------+
    '+      SD SPI Send/Recv Routines... (write/read byte/long simultaneously)     +
    '+              /CS=0 & CLK=0 on both entry and exit                           +
    '+-----------------------------------------------------------------------------+
    _recvlong       neg     dataout,          #1            ' call here to Recv a Long (+send 1's)
    _sendlong       mov     bitscnt,          #32           ' call here to Send a Long (long=32bits)
                    jmp     #@_sendrecv                     '
    _sendFF                                                 ' call here to Send $FF Byte
    _recvbyte       neg     dataout,          #1            ' call here to Recv a Byte (+send 1's)
    _sendbyte       rol     dataout,          #24           ' call here to Send a Byte (msbit first)
                    mov     bitscnt,          #8            '                          (byte=8bits)
    _sendrecv       mov     reply,            #0            ' clear reply
    ' 8+15 low/high clk cycles (8.7MHz@200MHz, 1.3MHz@30MHz)
    .nextbit        rol     dataout,          #1        wc  ' \ prepare output bit (DI=0/1)..
                    outl    #sd_ck                          ' | CLK=0  (already 0 first time)
                    outc    #sd_di                          ' / write output bit: output on CLK falling edge
                    waitx   #2                              ' |   setup time to be safe
                    outh    #sd_ck                          ' \ CLK=1
                    waitx   #3                              ' |   setup time to be safe
                    testp   #sd_do                      wc  ' | read input bit:   sample on CLK rising edge
                    rcl     reply,            #1            ' / accum DO input bits
                    djnz    bitscnt,          #.nextbit     '   8/32 bits?
            _RET_   outl    #sd_ck                          ' CLK=0 on exit
    '+=============================================================================+
    
  • Just on the above code, calling _recvlong instead of _sendFF might be enough to fix this (without changing code length)
  • You need cs high and then extra clocks to release the DO line. The card itself needs extra clocks after the operation but it doesn't care if cs is high or low for that part.
  • Here's some fresh data from new cards

    Toshiba 16 GB SDHC (reports as Panasonic in Taqoz) - needs 1 extra clock to release MISO
    Samsung EVO+ 64 GB SDXC - needs 1 extra clock (same as Samsung EVO
    Verbatim Premium 64GB microSDXC - needs 1 extra clock

    SanDisk Extreme 64GB SDXC - DOES NOT RELEASE MISO - even with 40 or so clocks i tested with.


    Goes to show really need to test with multiple types even within a brand.
    That last one is from Officeworks (Red and Gold, instead of Red and Silver colour coding)
  • Here's the log from the 'unreleasable' Sandisk Extreme

  • TubularTubular Posts: 4,620
    edited 2019-02-22 01:58
    Ok there's another dimension to this. Some cards (SanDisk 64 GB SDXC Extreme and 16 GB Ultra SDHC) are able to boot multiple times despite not releasing the MISO line.

    Other cards (Samsung EVO, EVO+, and Team) will only reboot if they have released the MISO line to floating.

    Or, perhaps there is a physical pullup resistor so they show 3v3 on the MISO line, but internally the card logic has released the line.

    Anyway the good news is looks like all the Sandisk variants boot multiple times without having to be physically removed from the socket, which at least gives us a "don't have to think too hard" option

  • The Team card doesn't need 2, it only needs 1 additional pulse, then it can reboot OK, even though MISO is not floating.

    Perhaps its just the extra pulse thats works enough magic to cover all cases.

    Sorry for the twists and turns in this reporting. Its now looking like just adding that extra single pulse might be enough.
  • jmgjmg Posts: 15,140
    Tubular wrote: »
    ...
    Or, perhaps there is a physical pullup resistor so they show 3v3 on the MISO line, but internally the card logic has released the line.

    Could be, that's why the idea of a two-resistor biased level for testing is a good one. eg choose R's to bias 2.7~3.0V region. = Hi, but not at rail.
    You can see CMOS drive in both directions, and Float and also pullups too, on a scope.

  • yes, a really good idea.
  • Cluso99Cluso99 Posts: 18,066
    Tubular wrote: »
    The Team card doesn't need 2, it only needs 1 additional pulse, then it can reboot OK, even though MISO is not floating.

    Perhaps its just the extra pulse thats works enough magic to cover all cases.

    Sorry for the twists and turns in this reporting. Its now looking like just adding that extra single pulse might be enough.

    Not at all. Thanks for your great help in tracking this down :smiley:
    There just wasn't enough time because I had forgotten about this problem.

    Attached is v003d. You will require a small pulldown on P58 for this test to work. I have 15K.

    Hopefully this should fix all your cards. It debugs what DO was and is after the extra clocks. They are in one subroutine "check_DO".
    Currently I am sending 8*2 clocks which means 8 clocks. Just change the REP statement if you find you need more.
  • cgraceycgracey Posts: 14,133
    If we submit another ROM, we may get charged another $2500. We just had a conference call today about all this and I agreed there'd be no more changes. We're probably going to have to live with what ROM we've got.

    Just the same, might as well perfect it for future chances to submit a new ROM.

    I did get some layout changes made to the PLL loop filter which should improve the PLL performance quite a bit.
  • TubularTubular Posts: 4,620
    edited 2019-02-22 05:54
    Sounds like this sausage is stuffed, Chip. Does this mean its all in OnSemi's hands now?

    What do you work on next, Spin2 interpreter?
  • Cluso99Cluso99 Posts: 18,066
    No
    cgracey wrote: »
    If we submit another ROM, we may get charged another $2500. We just had a conference call today about all this and I agreed there'd be no more changes. We're probably going to have to live with what ROM we've got.

    Just the same, might as well perfect it for future chances to submit a new ROM.

    I did get some layout changes made to the PLL loop filter which should improve the PLL performance quite a bit.

    That's fine Chip.
    I need to fully understand the problem and then I will get it fixed just in case there is another reason for a change.

    Great news about the PLL as that's been bothering me because of the jitter I had seen. Hopefully it will fix a few things we've seen.
  • cgraceycgracey Posts: 14,133
    Tubular wrote: »
    Sounds like this sausage is stuffed, Chip. Does this mean its all in OnSemi's hands now?

    What do you work on next, Spin2 interpreter?

    Yes and yes.

    (In trying to respond to your post, I accidentally edited it, though it's unchanged.)
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-22 06:33
    Yeaaaah Chip :smiley::smiley::smiley:

    Have to draw the line in the sand sometime. There will always be one more thing.

  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-23 12:00
    Here is v003n SD Booter.

    There is a lot of debug information output. In particular, the SD-DO is tested and reported. The first value (typically 1) is before I send 8 clocks and the second value (should be 0) is after the clocks. If the second is not 0, then it will be followed by *****. Please let me know if you find any of these.
    Oh, and you'll need a 10K+ pulldown on P58 for my testing.

    Hopefully I've nailed the DO release problem. Also, I've done some code rework including booting from exFAT formatted SD cards - yes it can find a file named as 8.3 in the root directory and load/run it. I removed code which was not of any use, such as reading the CSD, CID, FSI sector and FAT sector. And I am certain I've not violated any MS purported patents. Writing files to the card may be a different matter tho.

    Beware, the format must be 8.3. In exFAT the decimal is included in the filename and I require the decimal to be in the 9th character position!!! This is not a problem for booting since the ROM will be hard-coded to "_BOOT_P2.BIX" and "_BOOT_P2.BIY".

    There is no guarantee this will make it into the silicon, or will fit either, but I'll be ready just in case ;)
  • Cluso99Cluso99 Posts: 18,066
    Yep, saw those. But at US$449 for 1TB I think I'll be waiting for a feeew years before I'll buy any.
  • 1TB available... the SDXC spec only goes to 2TB doesn't it?

    Wonder what happens then, and can we boot from whatever comes next?

  • Ok that'd be SDUC next, also based on exFAT.
Sign In or Register to comment.