SD Boot code in ROM - misconceptions???
Cluso99
Posts: 18,069
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.
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
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.
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:
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 ???
I love the "needs more editing" comment - yes indeed it does!
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.
I can't find anything in the SPI protocol documentation to set these options. How do you specify which mode to use?
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_____XWhere 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_____XShould 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",0Boot times before (black screen after I press reset):
Boot times after:
The significant change being sysclock at 300 MHz instead of the default RCFAST (~ 25 MHz).
If I do the following, with no SPI Flash installed, can I have the 100ms window and then boot from SD if no serial boot? I know that P61 is the CLK line on the SD card.
P61 - Pullup
P60 - Pullup (internal to SD)
P59 - Float
Nope. P61 pullup disables SD booting. P59 pullup disables both EEPROM and SD booting. Otherwise a bootable SD always boots first.
I can boot SD or program RAM on the Edge with Flash Off and P59 floating. Maybe this is due to the state the SD card is in. which prevents booting. I will fool around a bit to try and figure it out.
The only state for a bootable SD card to not boot would be not responding - needs a power down.
I reported on our testing in Feb 2019. The issues we found during detailed testing in Feb 2019 are in this thread
https://forums.parallax.com/discussion/169743/p2-sd-boot-rom-v2-for-p2-respin-feb-2019-exfat-trial/p6
That too.
Okay, so that's a do it with every program thing: Test P59 P60 for a pullup and if a card is present toggle the SD clock a few times.
Yes, I added this to my code in order to perform a soft reset and it actually reboots. I send CMD0 when the sd card is dismounted, as I recall. The details of that are fuzzy.
Yeah, that pretty much happens everytime I press reset with the SD card mounted. I am going to have a circuit that will power cycle the SD card upon reset or brownout on the new board.
The board I am designing will not have flash. Only SD. I want the ability to program it via serial in the development phase. Just trying to figure out a way to get a programming window like I do with the Edge. This use case isn't documented.