Shop Learn
SD Boot code in ROM - misconceptions??? — Parallax Forums

SD Boot code in ROM - misconceptions???

Cluso99Cluso99 Posts: 18,062
edited 2020-11-10 00:48 in Propeller 2
SD Boot code in ROM

There seems to be some misconceptions that it's not reliable. This is definitely not the case as far as I know.

Some history...
I have been using SD cards successfully on the P1 for over 10 years. In many of those designs I share the pins with SRAM (my RamBlade boards) without problems once I patched the various software drivers for a bug in some SD cards not releasing DO drive low after SD access completes.

I always recommend using SanDisk SD cards as these seem to work reliably whereas other brands seem to have various issues as has been reported on various websites over the years. Even though I have only shipped legitimate SanDisk microSD's, I have used many other brands without problems.

I wrote the SD boot code in ROM for the P2 Rev A. There was a problem that some SD cards failed to release driving the DO pin low, resulting in a problem if the Flash chip was subsequently accessed after the P2 had booted or tried to boot from the SD. In all cases where the P2 booted from Flash there was no problem. This was because in my rewrite of the SD driver for P2 I missed some of the DO cleardown routines. Note there were only about 110 Rev A chips ever made, and they are now obsolete due to other instruction improvements made to the chip.

I fixed the SD boot code for the P2 Rev B (which is identical in Rev C) to make a more robust cleardown of the DO problem. I wrote the SD code to be able to be called from user programs but due to philosophical changes the ROM code is no longer guaranteed to be present for your code to call these (and the monitor and TAQOZ routines) after spin has run. Why is this important? Well, I discovered there was still an obscure way (and I forget now anyway) that you could call these routines and miss the DO cleardown failsafe routine. But since you're not calling these routines now, it doesn't matter.

So, when the P2 (Rev B & C) boots and goes through the ROM code to test for the SD card, whether it is present or not, the SD card is forced by software to tri-state the DO pin. So there should be no circumstances (and I am not aware of any) where the DO pin is being left driven after boot.

Note 1: On the P2-EVAL the LED on P58 is connected to the SD DO pin. To verify that the DO is being driven low (the bug) place a pullup >=10K (100K is better) on this pin to 3V3. If the P58 LED is then ON (not flashing) after the SD card has been accessed, then DO is not being released.
Note 2: This is actually a bug in the SD card implementation, not in our code. The SD card is supposed to release DO after a transaction is completed.

If you do find a problem, then please report it.

Comments

  • RossHRossH Posts: 4,845

    Hi Cluso

    This has probably been discussed elsewhere, but this seems like a good place to add it for future reference anyway.

    The P2 documentation is not clear that is a difference in the behavior of some P2 board and SD card combinations depending on the state of the boot switch marked "P59 v" on the P2 Eval board, or just "v" on the P2 Edge board.

    I have some SD cards (e.g. SanDisk 8Gb and 32Gb) that work properly with this switch in either position, as the documentation appears to imply they should. But I have other SD Cards (e.g. Verbatim 16Gb) that will only work correctly when this switch is ON.

    It also depends on the board - When this switch is OFF, the P2 Edge will not boot from these Verbatim cards, either using the reset switch or a software reset, but the P2 Eval will boot from them when using the reset switch, but not when using a software reset.

    Ross.

  • Cluso99Cluso99 Posts: 18,062

    The "P59v" / "v" indicates a pull-down on pin P59.
    If an SDcard is plugged in, then it will supply a pull-up on P60 (CSn).
    If there is no pull-up on P61 and P59 has a pull-down (P59v/v switch on) then the boot process will not try serial which means the SD boot process will start quicker.

    The implications of the P59 pull-down are:

    • Faster boot time (100ms serial testing is skipped)
    • If P61 has pull-up then only SPI Flash will be tried
    • If P61 is floating (no pull-up) and P60 has pull-up (SD card present) only SPI SD will be tried

    I wonder if the Verbatim cards cannot cope with the SPI Flash being tried first ???

    As for the reset switch, there is a 240 ohm serial resistor between the SD DO pin and the Flash DO / P58 on the P2EVAL RevB.
    There is no SD Card on the older P2EDGE boards so this resistor would not be present. Perhaps this also has something to do with the Verbatim cards ???

  • RossHRossH Posts: 4,845

    I love the "needs more editing" comment - yes indeed it does! :)

  • evanhevanh Posts: 13,106
    edited 2022-06-05 04:33

    It's wise to use SPI clock mode 3 (CPOL=1, CPHA=1) when both devices are accessible. Otherwise CS activation gets tricky.

    All SD code I've seen so far is using mode 0 (CPOL=0, CPHA=0). This mode can easily trigger unintended responses from the EEPROM. And vice-versa, operating the EEPROM in mode 0 will likely elicit unintended responses from the SD card.

    PS: I recently changed Flexspin's SD routines, for the Prop2, to mode 3.

  • RossHRossH Posts: 4,845

    @evanh said:
    It's wise to use SPI clock mode 3 (CPOL=1, CPHA=1) when both devices are accessible. Otherwise CS activation gets tricky.

    I can't find anything in the SPI protocol documentation to set these options. How do you specify which mode to use?

  • evanhevanh Posts: 13,106
    edited 2022-06-06 12:00

    You won't find anything for device config. Mode 3 uses the same rising edge as mode 0. So, although most slave device documentation is for mode 0, said devices are happy if mode 3 is used instead. The master just has to tweak its timing to align first bit of command/data out, and allow for the fact that slave data out on falling edges appears later, ie: after first data clock edge (which is falling), instead of being present from end of command ...

    Here's a significant timing difference for the master:

          SPI Clock Mode 0
     =========================
         ---CA Phase--|       |--Data Phase--
              __    __            __    __
     CLK  \__/  \__/  \__________/  \__/  \
           _____ _____ ____________________
    MOSI  X_____X_____/
                       _____________ _____
    MISO  ____________/_____________X_____X
    

    Where mode 0 has the slave's first data bit presented (for the master to sample) upon the final falling clock edge of command-address phase. In mode 3, this is postponed until the that same falling clock edge occurs later at the start of data phase.

          SPI Clock Mode 3
     =========================
         ---CA Phase--|       |--Data Phase--
              __    __________    __    __
     CLK  \__/  \__/          \__/  \__/  \
           _____ _____ ____________________
    MOSI  X_____X_____/
                               _____ _____
    MISO  ____________________/_____X_____X
    
  • Wuerfel_21Wuerfel_21 Posts: 2,782
    edited 2022-06-06 10:10

    Should probably post this here, too, for relevance.

    Since the SD bootloader takes about 8 seconds to load a full RAM image, here's a hack that makes it significantly faster: Simply use this little stub as your _BOOT_P2.BIX and have it load the actual program:

    CON _CLKFREQ = 300_000_000
    DAT
                  org 0
                  asmclk
                  '' Patch pullup check
                  wrlong #0,##$fc5b4 ' not sure why it fails but ok
                  '' Move filename into place
                  mov $1DC,name+0
                  mov $1DD,name+1
                  mov $1DE,name+2
                  drvh #38 ' Set LED
                  call #$fc578
                  drvl #38 ' Clear LED if fail
                  jmp #$
    
    name          byte "LOADTEST","BIX",0
    

    Boot times before (black screen after I press reset):

    Boot times after:

  • evanhevanh Posts: 13,106
    edited 2022-06-06 10:44

    @Wuerfel_21 said:
    ... here's a hack that makes it significantly faster ...

    The significant change being sysclock at 300 MHz instead of the default RCFAST (~ 25 MHz).

Sign In or Register to comment.