STM32Cube_FW_F4_V1.5.0 Bug on SD+FatFS+FreeRTOS

[zh_jianjun]

Posted on April 23, 2015 at 06:57

Last post was missing maybe because the slow network. Just see my git commit:

https://git.oschina.net/dingtu/STM32Cube_FW_F4_BugFix/commit/f4d5409e0cf7ff5cc199c130616deff42c684a71   fix: SD_RX_OVERRUN error when used in multithread RTOS, change to use DMA   fix: SD_DMA_RxCplt() dead locked cause by while(hsd->SdTransferCplt == 0)   fix: SD_DMA_TxCplt()dead locked cause by while(hsd->SdTransferCplt == 0)

[diabolo38]

Posted on April 24, 2015 at 17:35 to make HAL driver usable with freetos you best redifined (overload) HAL_GetTick() to rely on you any timer at 1000Hz free rtos bring the systick interrupt to lower level that will many time out in variuosu driver to fail SD is just one case That's an example

void
HAL_IncTick()
{
/* default weak arround FreeRTOS and systick get wrong due to low priority remap on FreeRTOs
* it brake HAL_Deay and HAl_GetTikc base timeout and over bad delay and waiting in ISR
* a new mechanism is designed below */
}
void
HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim){
if
( htim == &htim14){
TIMx_uwTick++;
}
}
/*
* New HAL_GetTick version for HAL driver that is FreeRTOS compliant
*
* double check priority of tim14 and task/interrupt making use of tick HAl_Delay
*/
uint32_t HAL_GetTick(
void
){
return
TIMx_uwTick;
}

[arman1371]

Posted on December 15, 2015 at 14:37

Thanks for solution,

I used your changes (Using DMA instead of polling for SDIO write and read), it fixed Overrun errors but I am still getting random!! failures on BSP_SD_Init() I am using the most recent STM32F4Cube (v 1.10.0). It is very strange, is there any official fix?? Is ST aware of this problem?

[michaelisaev9]

Posted on February 07, 2016 at 15:45

Hi.

Check that preemption priority of SDIO handler is higher than that of DMA handler.DMA handler waits for SDIO interrupt to set complete flag (SdTransferCplt

)

.So DEADLOCK is not a bug, it's a result of incorrect preemtion settings.