7 years, 11 months ago.

Questions about initialization failures with Neil's SDFileSystem

I've noticed a couple of initialization failure conditions with Niel Thiessen's SDFileSystem, and I'm wondering if they are expected failures or bugs.

First of all, I've noticed with many different SD cards that if I hit the reset button while using the card, the next initialization will fail (CMD0 returns 0xFF). Depending on the card, initialization tends to continue failing on reset until I reseed the card. This doesn't seem particularly odd to me, since the reset button doesn't necessarily do a hard reset on the SD card. But is there a way to handle initialization or prep the card so that it still works after a software reset?

Secondly, I noticed that the SDFileSystem was recently updated so that the timeout for ACMD41 (and some other operations) is 1000 tries instead of being a period of time. I didn't test under the older code, but with one PNY 64GB microSD card, 1000 tries isn't enough; it fails every other time or so. If I increase the number of tries to 2000, it seems to work fine. Is there any documentation that says how many tries is enough? ChaN says it "can take hundreds of milliseconds (large cards tend to longer)," and the formal spec says "The host shall set ACMD41 timeout more than 1 second" (part1_410.pdf, page 27). Is there any way to translate that into a hard number of attempts?

Thanks!

2 Answers

7 years, 11 months ago.

Hi Aaron. In regards to your first question, I don't think there's any way to reset a card that's locked up because the host reset in the middle of communication. If I recall correctly, the SD card specification recommends using a MOSFET power switch for such scenarios.

In regards to your second question, I'll take a look at the ACMD41 timeout. I may have chosen that value arbitrarily.

Accepted Answer

Thanks! Let me know if you find more info on the ACMD41 timeout, otherwise I'll roll with a higher number for now.

posted by Aaron Campbell 24 May 2016

I checked the SD card physical layer specifications, and they specify a timeout value of "at least 1 second" for ACMD41 in one place, and recommend "more than 1 second" in another. Got to love ambiguous specs... Anyway, I updated the library to use a 2 second timeout for ACMD41 and CMD1 instead of the blind loops. Let me know if this works with your problem card, if not I can increase this further.

posted by Neil Thiessen 24 May 2016

Seems to work! The PNY SD card takes as long as 800ms; a few other cards seem to take 50-200ms (less on subsequent initiation after a software reset).

Also, I didn't get it to re-init after interrupting an I/O operation, but I did add a retry loop on CMD0 that fixes it so it successfully re-inits after a safer software reset (e.g. hitting reset after the program finishes, which would sometimes cause init to fail on certain cards). (Similar things have been done to the "official" SDFileSystem: https://developer.mbed.org/questions/833/SD-card-doesnt-initialize-only-the-first/)

posted by Aaron Campbell 25 May 2016

Hi Aaron. I added a retry loop to the dummy clock/CMD0 section of the initialization routine. I'm not sure why this is necessary since the SD card physical layer specifications don't mention anything, but let me know if it fixes your problem card.

posted by Neil Thiessen 26 May 2016

I agree that it doesn't seem necessary - but these aren't commercial grade SD cards I'm testing, so maybe they cut some corners.

The loop does fix the reset-init problem on the PNY card. I just found that if you increase the retry count to over 20, it also fixes it so it will successfully re-init after a hard reset that interrupts an I/O operation. I'm not sure if you want to go that far, but you might be interested to know. (The most retries I've seen in that scenario is 18, with or without a debugging printf() taking up CPU time. Tested with several different sized SanDisk cards and the PNY.)

posted by Aaron Campbell 26 May 2016

Hi Aaron. I suspect the reason so many retries is required after a hard reset is because the card was in the middle of a block read or write. In which case, clocking it until it responds is probably not a good idea since you could be inadvertently overwriting data.

posted by Neil Thiessen 27 May 2016
7 years, 11 months ago.

For me, Neil's SDFileSystem (v23) was working fine on a K64F until earlier this week when mbed went from 119 -> 120, mbed-rtos 111 -> 115 and EthernetInterface 52 -> 54.

A lot of stuff broke after that update - including I2C.

What platform are you using? And what versions of code?

...kevin

I'm also on a K64F, but I don't think this would be related to any of those issues. The library works great apart from the specific initialization failure cases. I'll have to try the most recent mbed versions you're talking about though. Did SDFileSystem stop compiling, or did it stop initializing, or what?

posted by Aaron Campbell 18 May 2016

I did run into a few compiler issues, but fixed those. Now, the SD freezes on mounting and I2C sees different devices (0x10, 0x80 & 0x90). It should be seeing 0x20 and 0x3A (the internal FXOS8700CQ)

posted by Kevin Braun 19 May 2016

Ok. Yep, looks like I'm getting the freeze-on-mount thing as well. I'm going to see if I can figure out why.

posted by Aaron Campbell 19 May 2016

It appears the root issue is that SPI is broken on the K64F in mbed 120. This has been reported on GitHub here: https://github.com/mbedmicro/mbed/issues/1754 . Kevin, maybe you should add your comments about I2C and anything else you know is broken.

posted by Aaron Campbell 19 May 2016

I just did Aaron - thanks. I hope that this was the correct thread and not starting a new thread instead.

posted by Kevin Braun 19 May 2016