Shop OBEX P1 Docs P2 Docs Learn Events
Initializing SD Card always fails on first attempt - why? — Parallax Forums

Initializing SD Card always fails on first attempt - why?

agsags Posts: 386
edited 2013-10-04 20:40 in Propeller 1
I've developed a highly-specialized SD card driver, and had to make it very lean to fit in cog RAM. It works, but I see that every time I first insert an SD card, the initialization process fails. If I run it again, it will succeed each subsequent time.

I reviewed the fsrw code by lonesock et al, and notice that implementation tries up to 10 times to reset ("GO_IDLE") the SD card. Why is this? If a card is removed (from power) and re-inserted, isn't it then in a known state?

The failure I see is always at the first step, CMD0. The return error code varies, but after trying again it will succeed. I suppose I can just loop through this command several times until it fails, but this type of "it works but I don't know why" solution seems to always come back with a vengeance.

Any insight into this? Thanks.

Comments

  • Heater.Heater. Posts: 21,230
    edited 2013-09-30 10:44
    No code, no idea.
  • ElectricAyeElectricAye Posts: 4,561
    edited 2013-09-30 10:57
    ags wrote: »
    ... every time I first insert an SD card, the initialization process fails. If I run it again, it will succeed each subsequent time.....

    I'm just taking a wild guess here. Do you have a line of code that checks for the presence of an SD card in the slot and did this presence-detection get slipped down in your code someplace so it's not getting satisfied before you start all your other initializations on the first try, etc.?
  • jazzedjazzed Posts: 11,803
    edited 2013-09-30 11:03
    We have found that sometimes an SD Card can get stuck in SD Card mode rather than SDIO mode at startup. There is a sequence to ensure SDIO operation. Not sure what it is at the moment though.
  • agsags Posts: 386
    edited 2013-09-30 12:40
    1 - will have to wait until tonight to post code. It's pretty straightforward SPIN code for the initialization
    2 - that was a good idea. I do detect presence of the card (don't recall which pin has the pullup) but it's the first thing I do.
    3 - I'm not using or supporting SDIO cards, just SD (SDHC, to be precise). But this is more along the line of what I was wondering. I have read and re-read the SDC spec many times, yet I haven't noticed any discussion of a card being "stuck" in a particular mode. I can see that if in the middle of a block operation the card was removed that might leave it in an unusual state, but would expect it to always return to a known starting state when power is applied.
  • jazzedjazzed Posts: 11,803
    edited 2013-09-30 13:07
    AFAIK all Propeller SD Card drivers use 4 pin SDIO mode. Did you write one for SD Card mode?
  • agsags Posts: 386
    edited 2013-09-30 14:14
    Perhaps my terminology is incorrect. I use SDIO to refer to SD Cards with enhanced capabilities that allow use for IO (e.g. wireless). It was an enhancement to the base specifications. I refer to the two protocols used by SD Cards as SD (the "native" protocol, capable of 4-bit wide data flow) and the SPI protocol, similar to standard SPI.
  • jazzedjazzed Posts: 11,803
    edited 2013-09-30 14:30
    ags wrote: »
    Perhaps my terminology is incorrect. I use SDIO to refer to SD Cards with enhanced capabilities that allow use for IO (e.g. wireless). It was an enhancement to the base specifications. I refer to the two protocols used by SD Cards as SD (the "native" protocol, capable of 4-bit wide data flow) and the SPI protocol, similar to standard SPI.

    It's OK :)

    I was just curious. I know for example that the Spinneret board has all pins hooked up for standard SD mode, and it would be interesting to see how that would work.

    Our drivers should set SDIO (not SD mode) on first use to avoid trouble ... whether the all propeller SDIO SPI drivers do or not is unclear.
  • agsags Posts: 386
    edited 2013-09-30 14:55
    Yes, I agree, and CMD0 is the first step in setting SPI mode (not SD mode). That's where the failure occurs (only the first time after inserting/powering up).
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2013-09-30 16:21
    I have no clue as to the Why part, I can not find any documentation on it. It seems that looping on CMD8 is the rule of thumb.

    Though, today, I did take the time to look at a large number of existing Open source drivers for SD Cards on many different MCUs and boards and they all seem to loop on CMD8 until they succeed, so I would say that it is probably an issue with the SDCard manufactures implementations. My drivers do this just to be sure to operate correctly, though before today I had never took the time to look at so many other sources.

    Many of the SD Card HowTos for many different devices say that this is what you do though fail to say why.

    Though thank you for raising the question.
  • agsags Posts: 386
    edited 2013-09-30 17:46
    Wow, that's ... interesting. Perhaps troubling? As I said, I read and re-read the SD Card spec many times. I have a functional understanding, and also have come to the opinion that it is really pretty poorly done.

    Would you be so kind as to post links to the SD Card HowTos you reference? Thanks.
  • Mike GreenMike Green Posts: 23,101
    edited 2013-09-30 17:48
    Do have a look at SDSPIFEMTO.SPIN which is part of FemtoBasic. It combines an I2C driver and loader with a low-level SD card driver and loader. Also look at SPHINX's SD card driver. Both of these fit in a cog. The SD card driver in SDSPIFEMTO could be separated from the I2C driver to make significant space available in the cog's RAM.
  • msrobotsmsrobots Posts: 3,709
    edited 2013-09-30 18:23
    It might be a power issue.

    Maybe this is not related. As I was working on the RAISD driver I had a prototype build by Kenichi (@MacTuxLin).

    The funny thing was that rebooting (switch power on/off) failed to Init the SD cards - when USB (Prop Plug) was connected.

    It turned out that the Prop Plug was powering the board thru rx/tx (just minimal ... VERY dim led showed still power there)

    My solution (during development) was to either unplug the Prop Plug or remove the SDs and reinsert them.

    The available SD documentation states that ALL SD cards will startup in SD mode (not SPI) and have to be initialized to SPI direct after power up or reset.

    Reading your description I wonder if you insert the SD into a powered up board?

    FSWR (and lonesocks super driver) do not check for sd-change (KYEs Fat_Engine does - maybe you can look at his code at the beginning of the PASM part)

    So - just a guess - Does your initialization is maybe TO LATE to switch the SD card into SPI mode and thus failing?

    Since the SD card association published the 4 bit mode description I am pondering over a non SPI driver.

    But as far as I understand the documentation switching OFF the checksum just works in SPI mode.

    while receiving we can just ignore the checksum. But when sending CMDs or Data that checksum needs to be calculated for EVERY DATALINE (BIT) SEPERATLY.

    I still think it is worth a try - even if writing may be slower - reading will be faster for sure ...

    Enjoy!

    Mike
  • agsags Posts: 386
    edited 2013-10-03 18:51
    The init fails when the card is already inserted at power-up. I don't have a PropPlug (or similar) attached.

    I just took a look at the Spinneret schematic and noticed that all four SPI lines (MISO, MOSI, SCLK and SCS) have pullup resistors - I have none. I wonder if that is a factor. I wouldn't expect so, unlike an I2C interface.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2013-10-04 05:33
    ags wrote: »
    Wow, that's ... interesting. Perhaps troubling? As I said, I read and re-read the SD Card spec many times. I have a functional understanding, and also have come to the opinion that it is really pretty poorly done.

    Would you be so kind as to post links to the SD Card HowTos you reference? Thanks.

    Well here is a good one (targets the AVR though still quite generic).
    http://elm-chan.org/docs/mmc/mmc_e.html

    and another(this one showing a scope of the init):
    http://www.esawdust.com/blog/serial/files/SPI_SD_MMC_ATMega128_AVR.html

    There are many more, though I no longer have them bookmarked.
  • Dave HeinDave Hein Posts: 6,347
    edited 2013-10-04 05:40
    Try a bypass cap across the power and ground near the SD card. That solved the same problem I was having about a year ago.
  • agsags Posts: 386
    edited 2013-10-04 10:24
    Thanks Dave. I thought of that at one time but didn't try it. My prototype is pretty sloppy with wire length, capacitance, bypass/decoupling, etc.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-10-04 13:47
    You need 10uF and 0.1uF right at the card socket pins. Length of wires has found to be a problem. A 10K pullup should be on /CS.

    Aonther problem I found is that the card has to be forced to release the DO pin by sending a number of clocks. This doesn't sound like the problem but could try it anyway.

    IMHO you really need a propplug or equivalent to debug. Do you have any USB-TTL boards? There are lots of cheapies using the CP2102??? chip. You just eed to add the DTR (or RTS line with the transistor reset circuit which is simple and basic - almost any generic npn transistor, 10K, 10nF.
  • agsags Posts: 386
    edited 2013-10-04 14:16
    @Cluso99: I will try the caps, that sounds like an issue. I'm not following the PropPlug recommendation. I do have one (but I am using the Prop ProtoBoardUSB), and a logic analyzer, and an oscope. How would they be used for debugging this - although it may be a moot point if the caps fix the problem.

    The code is sending the correct signals (AFAIK, given my understanding of the SDC specification) and works except for the first time the card is powered up. It's just that the card does not respond with the expected $01 response. I have not looked at the VDD pin with an oscope to see if there is noise/ringing/glitches that may point to the decoupling/bypass capacitor problem.

    Thanks for the suggestions.
  • SapiehaSapieha Posts: 2,964
    edited 2013-10-04 20:40
    Hi jazzed.

    It is for at people not fold SD recomendations on poling a unused SD pins High

    I see someone has already mentionde 10uH Capacitor
    jazzed wrote: »
    We have found that sometimes an SD Card can get stuck in SD Card mode rather than SDIO mode at startup. There is a sequence to ensure SDIO operation. Not sure what it is at the moment though.
Sign In or Register to comment.