1
\$\begingroup\$

Issue

I'm attempting to mount an SD card to my STM32F407 with Elm Chan's FATFS using SDIO and f_mount returns FR_DISK_ERR.

The following sequence of functions is called from there:

mount_volume() > check_fs() > move_window() > disk_read()

Ultimately, my error resides in disk_read, more specifically where the SDIO_STA_RXDAVL bit of SDIO->STA never gets raised, meaning there is no data avaialbe in the FIFO to be read, as commented below:

cmd = (count > 1) ? 18 : 17;
t = msTicks;
rd = 0;

SDIO->DCTRL = ((0b1001 << 4) | SDIO_DCTRL_DTDIR);
SDIO->DLEN = (512 * count);
SDIO->DTIMER = (400000);

sta = 0;
if (!send_cmd(cmd, sector, RESP_SHORT, &resp) || (resp & 0xc0580000))   /*!MOD REG?*/
    return RES_ERROR;
SDIO->ICR = (0xFF);
SDIO->DCTRL |= (SDIO_DCTRL_SDIOEN   |
                SDIO_DCTRL_RWSTART  |
                SDIO_DCTRL_DTDIR    |
                SDIO_DCTRL_DTEN
               );

while (elapsed(t) < 1000) {

    sta = SDIO->STA;

    if (sta & (SDIO_STA_DTIMEOUT | SDIO_STA_RXOVERR | SDIO_STA_STBITERR)) {
        err("%s SDIO_STA: 0x%08X\n", __func__, (uint)sta);
        break;
    }

    if (sta & SDIO_STA_RXFIFOE)
        continue;

    if (rd == 0 && !(sta & SDIO_STA_RXDAVL))
        continue;      //<<---No data available, so can't get to FIFO

    data = SDIO->FIFO; //<<---Never gets here

    buf[rd++] = data;
    buf[rd++] = data >> 8;
    buf[rd++] = data >> 16;
    buf[rd++] = data >> 24;

    if (rd == 512 * count)
        break;
}

if (rd < 512 * count || cmd == 18)
    send_cmd(12, 0, RESP_SHORT, &resp);

return SDIO->DCOUNT ? RES_ERROR : RES_OK; //<<---Returns ERROR

I think my SD cards are responding alright, especially since the code returns what kind of SD it is (SD2) and the OCR (0x0080FFC0). I also checked CLK and CMD with the scope and they seem to be alright. There is no activity in any of the D[0:3] lines, though.

Why am I getting stuck?


Setup

\$\endgroup\$
4
  • \$\begingroup\$ Is there a reason you are not using the driver stack provided by ST? It basically includes FATFS. \$\endgroup\$
    – Justme
    Aug 23, 2022 at 20:23
  • \$\begingroup\$ You mean the HAL library @Justme ? If so, project requires bare-metal \$\endgroup\$
    – mgmussi
    Aug 23, 2022 at 20:44
  • \$\begingroup\$ If so, maybe it also requires re-inventing the wheel? The HAL exists so you can use it or use it as an example for your own code. \$\endgroup\$
    – Justme
    Aug 23, 2022 at 21:37
  • \$\begingroup\$ @Justme I mean, I'm not re-inventing the wheel necessarely. I'm using the FATFS library and Aurelio's code. Also, I know that HAL uses Elm's implementation of the FATFS \$\endgroup\$
    – mgmussi
    Aug 24, 2022 at 10:57

1 Answer 1

1
\$\begingroup\$

My problem was with the hardware. Although I cannot put a finger on what was the problem, I'll guess that the SD adapter was broken or had a weird pinout. Also, having only the internal GPIOs pull-ups (30k to 50k Ohms) was enough and I didn’t need the physical resistors I was adding to the circuit.

Moreover, my breaking points were generating weird results since the SD is a microprocessor itself. Therefore, every breakpoint would influence clocks and couters from the SD and the were messing up my debugging. Once I got them out of the way, the response came out positive using the embedded SD slot that came with my board.

Another problem that I found was that only the FAT32 card was accepted. ExFAT cards did not get recognized, always returning FR_NO_FILESYSTEM. Below the output of all my testing conditions:

Card Type Circuit Type GPIO_PUPDR Response
FAT32 Embedded Circuit Pull-Up FR_OK
FAT32 Embedded Circuit *Pull-No FR_NOT_READY
FAT32 *SD Adapter Circuit Any FR_DISK_ERR
*ExFAT Embedded Circuit Any FR_NO_FILESYSTEM

* The main factors that caused errors on each combination

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.