[DONE] SDC read fails.

[tmanev]

Hi,

I have a very strange problem. My program is working ok with an older toshiba 2GB micro SD card and with the newer one from the same manufacturer(2GB) I get errors.
I was able to debug the problem and found that it sometimes fails here while trying to read from the card.

Code: Select all

  if ((SDIO->STA & SDIO_STA_DATAEND) == 0) {
    chSysUnlock();
    return CH_FAILED;
  }

this is in sdc_lld.c. The board is the olimex STM32E407 . I would appreciate if you could help me.

Best regards,
Todor

[Giovanni]

Is anybody else able to duplicate this problem? I don't see an obvious problem there.

Giovanni

[Tectu]

I know this problem very well but usually, this really just occurs when you use the cards in SPI mode. The new cards don't support SPI anymore or the timings are just crap and therefore they are not working as expected. I never had any problems with SDIO. I have the Olimex E407 as well along with some others and I also use very old microSD cards (I mean old as in 256MB was the highest I could buy back then) with very new ones (8GB). As I said - never had any problems together with SDIO.


~ Tectu

[alexblack]

Hi.

I know this problem very well but usually, this really just occurs when you use the cards in SPI mode. The new cards don't support SPI anymore or the timings are just crap and therefore they are not working as expected. I never had any problems with SDIO. I have the Olimex E407 as well along with some others and I also use very old microSD cards (I mean old as in 256MB was the highest I could buy back then) with very new ones (8GB). As I said - never had any problems together with SDIO.
~ Tectu

I am using SD cards in my projects over five years. ALL cards including modern SDXC support SPI mode. I am using 64Gb SDXC over year. Most of the problems arises because of hardware compatibility, such as the amount of 'PULL UP' on pins or the card's current consumption, as well as mechanical problems such as not clean contacts of the card or card reader. Often microSD cards do not want to work in full size SD readers through adapters.
I have no 407 MCU, but my STM32F103 board in SPI mode works with any my cards. Soon I have to get a new board, where I can check the SDIO mode too...

[Tectu]

It's interesting... I still have this pair of SanDisk 2GB SD cards here (full size SD cards). They both don't work with SPI, I cannot make them working, but with SDIO, they work like a charm. I checked for hardware issues - nothing I could found. Also, I saw other people on the internet complaining about SPI issues with some cards but maybe this is really some lottery thing.


~ Tectu

[alex31]

I have had problems with different kind of sd card, some that i have resolved, some that i have not yet.

see this thread,
http://forum.chibios.org/phpbb/viewtopic.php?f=2&t=1014

with the solutions which are there, i am able to use any kind of sd card, only limitation is that i
cannot use fat32 filesystem, but everything work fine on any kind of sdcard with fat16 (< 4Gb) partitions.

Alexandre

[alexblack]

I agree that sometimes there are strange problems with some instances of memory cards.
But support for SPI mode is mandatory for SD cards:

https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

[Giovanni]

Anyway, the problem described is not related to the SPI mode, he is using the SDIO mode.

Giovanni

[alexblack]

Hi.
Finally I got a new board with support for SDIO interface. But sooner was delighted, as was faced with several problems. At this point, the board has STM32F103ZET and external ASYNC 16 bit SRAM on FSMC.
First of all, I tested the memory and its speed. After numerous reviews in the direction of non-forest documentation writers still able to configure it for maximum speed. The test showed ~ 24MB/sec, though the same code on the internal memory gives 48MB/sec. Next began testing of SDIO interface.
The first problem is that the driver may not always initialize a memory card. So out of the four cards that I had, it was found that the normal initialization goes only SDHC card (it was only one: Transcend 32Gb 4class), and the other three (Sandisk Ulra II 1Gb, Sundisk uSD 1Gb, NoName uSD 256Mb) do not work. After studying the problem I found that the cards can be made ​​to work in two ways:
1. Insert a small pause after the clock setup to SDIO module:

Code: Select all

 file ChibiOS\os\hal\src\sdc.c
...
191 bool_t sdcConnect(SDCDriver *sdcp) {
...
201  /* Card clock initialization.*/
202  sdc_lld_start_clk(sdcp);

>>> chThdSleepMilliseconds(10);

204  /* Enforces the initial card state.*/
205  sdc_lld_send_cmd_none(sdcp, MMCSD_CMD_GO_IDLE_STATE, 0);
...

2. Make some calls sdConnect in case of failure:

Code: Select all

/*
 * SD card insertion event.
 */
static void InsertHandler(eventid_t id)
{
  FRESULT err;

  (void)id;
  /*
   * On insertion SDC initialization and FS mount.
   */
  int retry = 5;
  for (;;)
  {
    if (sdcConnect(&MMC_PORT) == CH_SUCCESS) break;
    if (--retry == 0) return;
    chThdSleepMilliseconds(10);
  }
  DEBUG_TRACE("SD CARD CONNECTED OK - %d, SIZE IS %d Kbytes\n\r", retry, MMC_PORT.capacity/2);
  ....

Both methods are stable, although not sure if this is a normal solution to the problem ...
Then I began to test the read/write speed of the memory cards and ran into another problem: reading is working, while the writing is causing the error FIFO UNDERRUN. The reason for this error is that I used buffer in external memory, and it is not fast enough for this purpose. If use the internal memory buffer, and it working. Also helps decrease the frequency of SDIO interface. But again, this does not guarantee the appearance of this error in the future, when the processor can be loaded with other tasks. The right solution - is to use hardware-based flow control, but ERRATA states that it is not working properly. Is there a way for software implementation of this algorithm? And yet why old cards do not work without pause?

P.S. During testing, the one memory turned bad (SDHC 32Gb)

[Giovanni]

Hi,

Thanks for all the testing, I am sorry for your card.

Another possible solution could be to poll the card after enabling the clock in sdcConnect() several times before giving up and inserting small delays after each failed attempt.

Giovanni