2017-07-05 01:53 AM
While using SDMMC with FatFS to interface with SDCards occasionally I get Command Timeout when issuing:
SDMMC_CmdReadSingleBlock
This is when using new 1.7.0 drivers. Did anyone experience similar issue?
2017-12-02 01:17 PM
I believe this fix is included in 1.10.0 HAL for L4 and some other updated micros. IRQ clears out only STATIC_DATA_FLAGS.
2017-12-14 07:05 AM
No, this is not fixed (at least not on STM32F7). The workaround proposed here (which works for me) is to NOT clear our all STATIC_DATA_FLAGS.
See code snippet below. I'm not sure that this works for everyone, but it works for me...
/* Check current state of Command Register and don't clear those flags */
if (hsd->Context == (SD_CONTEXT_READ_SINGLE_BLOCK | SD_CONTEXT_DMA))
{
if (__HAL_SD_GET_FLAG(hsd, SDMMC_FLAG_CMDREND)) {
/* Clear only selected flags */
__HAL_SD_CLEAR_FLAG(hsd, ((uint32_t)(SDMMC_FLAG_DCRCFAIL | SDMMC_FLAG_DTIMEOUT |
SDMMC_FLAG_TXUNDERR | SDMMC_FLAG_RXOVERR |
SDMMC_FLAG_CMDSENT | SDMMC_FLAG_DATAEND | SDMMC_FLAG_DBCKEND)));
} else {
/* Clear all the static flags */
__HAL_SD_CLEAR_FLAG(hsd, SDMMC_STATIC_FLAGS);
}
}
else
{
/* Clear all the static flags */
__HAL_SD_CLEAR_FLAG(hsd, SDMMC_STATIC_FLAGS);
}
2017-12-14 09:04 AM
ST didn't updated F7 libs. I think the fix is only for L4 for now.
2019-02-18 02:14 PM
Thanks for working on this issue - your workaround solved my problem.
2019-02-24 11:22 PM
Dear ST community,
long story made short:
the workaround proposed here fixed the problem for me. Thank you!
Detailed description:
Am am using the STM32F4. I observed this problem as well, when I started to use FatFS on SDIO SD card with DMA templates (w/o DMA templates, this problem did NOT occur).
In my situation, the problem was relatively hard to trace - the system resettet randomly from time to time, something between once and up to five times per day. Reason for the reset itself was that the IWDG kicking in.
And the IWDG kicked in, because the controller got stuck in the function SDMMC_GetCmdResp1 in this loop:
do
{
if (count-- == 0U)
{
return SDMMC_ERROR_TIMEOUT;
}
}while(!__SDIO_GET_FLAG(SDIOx, SDIO_FLAG_CCRCFAIL | SDIO_FLAG_CMDREND | SDIO_FLAG_CTIMEOUT));
I applied the changes to the function SD_DMAReceiveCplt and modified it to use SDIO, so that my function now looks like this:
static void SD_DMAReceiveCplt(DMA_HandleTypeDef *hdma)
{
SD_HandleTypeDef* hsd = (SD_HandleTypeDef* )(hdma->Parent);
uint32_t errorstate = HAL_SD_ERROR_NONE;
/* Send stop command in multiblock write */
if(hsd->Context == (SD_CONTEXT_READ_MULTIPLE_BLOCK | SD_CONTEXT_DMA))
{
errorstate = SDMMC_CmdStopTransfer(hsd->Instance);
if(errorstate != HAL_SD_ERROR_NONE)
{
hsd->ErrorCode |= errorstate;
HAL_SD_ErrorCallback(hsd);
}
}
/* Disable the DMA transfer for transmit request by setting the DMAEN bit
in the SD DCTRL register */
hsd->Instance->DCTRL &= (uint32_t)~((uint32_t)SDIO_DCTRL_DMAEN);
/* CHANGED PART START*/
/* Check current state of Command Register and don't clear those flags */
if (hsd->Context == (SD_CONTEXT_READ_SINGLE_BLOCK | SD_CONTEXT_DMA))
{
if (__HAL_SD_GET_FLAG(hsd, SDIO_FLAG_CMDREND))
{
/* Clear only selected flags */
__HAL_SD_CLEAR_FLAG(hsd, ((uint32_t)( SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT |
SDIO_FLAG_TXUNDERR | SDIO_FLAG_RXOVERR |
SDIO_FLAG_CMDSENT | SDIO_FLAG_DATAEND | SDIO_FLAG_DBCKEND)));
}
else
{
/* Clear all the static flags */
__HAL_SD_CLEAR_FLAG(hsd, SDMMC_STATIC_FLAGS);
}
}
else
{
/* Clear all the static flags */
__HAL_SD_CLEAR_FLAG(hsd, SDMMC_STATIC_FLAGS);
}
/* CHANGED PART END*/
hsd->State = HAL_SD_STATE_READY;
HAL_SD_RxCpltCallback(hsd);
}
From my point of view, ST should seriously investigate this problem.
Thanks again, @Hockuba.Krzysztof and to all who have been working on this workaround!
Joachim
2019-09-30 04:36 PM
A co-worker found this post and let me know about it.
I'm here to say this works perfectly for our STM32F7 development.
Without this fix, we would would not have reliable SD Card support.
Thank you so much for finding the issue and posting the fix!
Additionally, this issue is still present in the 1.14 drivers (11/3/2018) from STM. Moreover, it appears the issues is still in the 1.15 drivers (2/7/2019).
I'm surprised, concerned, and a little worried that this bug has not been fixed yet.
2019-09-30 06:36 PM
>>I'm surprised, concerned, and a little worried that this bug has not been fixed yet.
Welcome to the ST Ecosystem, loads of other bear traps in there
2019-09-30 06:49 PM
Wow, Indeed doesn't look like there were any updates to F7 SDMMC driver which is a bit of a surprise! Glad it helped.
2019-10-01 08:24 AM
Hello,
This issue impacted all the STM32 series and the correction is already done for some series and will be done for the others.
I will check internally the status for the STM32F7 series and I will push to fix this issue as soon as possible.
Best Regards,
Imen
2019-10-03 11:21 AM
I too was affected by this problem using the STMF767.
Can anyone point me to the exact fix that ST plans to use for the STMF7 series?