Why SDIO of STM32F4 chip lost 0xF in FIFO buffer?

[DDong.3]

Hi,

Recently I debug STM32F413 with a SD card by SDIO interface, but failed in FATFS mount. At last, I did a simple test. The code wrote 512 bytes--0x00-0xFF(256 bytes), 0x00-0xFF(256 bytes)--to the first two sectors of SD card by HAL_SD_WriteBlocks, and then read out them by HAL_SD_ReadBlocks. The writing in was successful, because all the bytes in SD card can be seen by Winhex. But when the reading is finished, the lost of 0xF was observed. For example, it is 0x00-0x0F, 0x10 for the first 17 bytes in 512 bytes, the receiving buffer showed 0x00-0x0E, 0x01, 0x02. In this way, 4 bit of 0xF was lost and the buffer cannot receive enough bytes. In the beginning, I think it is the fault of HAL_SD_ReadBlocks fuction, but when DMA was used, the same problem repeated. So I suspect it resulted from SDIO->FIFO buffer of SDIO interface of the chip.

I am not very sure if you see this problem? And is it an absent of some settings of SDIO interface, or a hardware problem of SDIO->FIFO? Could you give your professional suggestions to solve this problem?

Your quick answer is very appreciated. Thank you very much.

Best Regards,

Miller

[Tesla DeLorean]

Don't view the SDIO peripheral registers in the debugger.

Disable Hardware Flow Control

After HAL_SD_WriteBlocks() you need to spin waiting for BSP_SD_GetCardState() to return MSD_OK

[DDong.3]

Hi,

As you suggested, HardwareFlowControl is disabled, and call HAL_SD_GetCardState after HAL_SD_ReadBlocks to check if SDIO is HAL_SD_CARD_TRANSFER. Of course, SDIO registers were not opened. But the results look worse, only 64 bytes can be received for a whole sector. My project and codes are attached, thus can help you repeat this problem with a SD card. At first, please write into the first two sectors of this SD card with 0x00-0xFF, 0x00-0xFF.

Thank you.

[Tesla DeLorean]

Does your issue occur in sectors 10-12, that way I don't have to trash my cards.

I would suggest dumping the data to the USART in an ASCII format, not just send the 512 bytes to the terminal.

Check timeouts are adequate, and instrument better so you can identify failure paths.

Consider using strlen()

I don't have a F413 board, might look to see if I can induce the issue on a F412 board, with my own code base. Can't commit time/resources to debug other's CubeMX projects.

[DDong.3]

As you said, the hex bytes were converted to be ASCII before they were dumped to Uart. But the result is same. After thinking about it, I guess that the fast streaming of SD card may cause the lost of SDIO fifo buffer. Then I tried some ways to test, including enlarging the SDIO clock divider, and turning off 4 bit wide bus. At last, when cancelling HAL_SD_ConfigWideBusOperation, SDIO can read the correct bytes from SD card. So do you think it is a fault of the software or hard ware of wide bus?

Two images are attached, the image with wrong bytes is what Terminal received by ASCII format, while the other is the right one after turning off wide bus.