Code stuck in SD_FindSCR Function

Waiting for the response. Please help if anybody have the solution.

Thanks in Advance.

Regards,

Lalabhai

I can confirm this behavior. The standard of Micro-SD cards demands that initialization is done with 1 bit bus and a slow clock. This is already perfectly implemented by HAL_SD_Init using an own init definition with 1 Bit and slower speed. However, when trying to widen the bus to 4 bit the described error above occurred.

After a lot of tries I found a better strategy: For your own high speed SD_InitTypeDef definition start with a slow variant (1 bit + clock divider) and increase speed before widening the bus. By this the full SD card initialization and the first part of the widen bus configuration is done with the robust slow speed. No worries the fast speed configuration is still applied because the HAL_SD_ConfigWideBusOperation also calls another round of SDIO_Init.

Here is a code example:

uint8_t BSP_SD_Init(void)
{ 
 uint8_t SD_state = MSD_OK;
 
 /* uSD device interface configuration */
 uSdHandle.Instance = SDIO;
 
 uSdHandle.Init.ClockEdge = SDIO_CLOCK_EDGE_RISING; /* warning NEG edge does not work. See errata */
 uSdHandle.Init.ClockBypass = SDIO_CLOCK_BYPASS_DISABLE;
 uSdHandle.Init.ClockPowerSave = SDIO_CLOCK_POWER_SAVE_DISABLE;
 uSdHandle.Init.BusWide = SDIO_BUS_WIDE_1B; /* Must be one bit for initial configuration. Widened later */
 uSdHandle.Init.HardwareFlowControl = SDIO_HARDWARE_FLOW_CONTROL_DISABLE; /* warning HW flow control does not work. See errata */
 uSdHandle.Init.ClockDiv = SDIO_INIT_CLK_DIV; /* bypassed for ~ +20% performance */
 
 /* Check if the SD card is plugged in the slot */
 if(BSP_SD_IsDetected() != SD_PRESENT)
 {
 return MSD_ERROR;
 }
 
 /* Msp SD initialization */
 BSP_SD_MspInit(&uSdHandle, NULL);
 
 if(HAL_SD_Init(&uSdHandle) != HAL_OK)
 {
 SD_state = MSD_ERROR;
 }
 
 /* Configure SD Bus width */
 if(SD_state == MSD_OK)
 {
 /* This is an essential Delay. Otherwise the following WideBusOperation can get stuck
 * in optimized builds. It is unsure and irrelevant if this behavior is caused by software
 * or hardware (RC-Delays, 4 bit lines in different lengths,...)
 */
 OSAL_SleepMs(1);
 
 uSdHandle.Init.BusWide = SDIO_BUS_WIDE_4B;
 uSdHandle.Init.ClockBypass = SDIO_CLOCK_BYPASS_ENABLE; /* Use 48MHz generated by PLL directly for SDIO clock line (instead of PCLK2 /(2+uSdHandle.Init.ClockDiv)) */
 uSdHandle.Init.ClockDiv = SDIO_TRANSFER_CLK_DIV; /* bypassed for ~ +20% performance */
 
 /* Enable wide operation */
 if(HAL_SD_ConfigWideBusOperation(&uSdHandle, uSdHandle.Init.BusWide) != HAL_OK)
 {
 SD_state = MSD_ERROR;
 }
 else
 {
 SD_state = MSD_OK;
 }
 }
 
 return SD_state;
}

By this the failure rate of the above described problem is reduced to 0 (before it was about 1 in 3-6 initializations). I am also pretty sure that the 1 millisecond sleep is not needed anymore.

Hi @LDesa.1​ 

Have you already fixed the bug?

What FW are you using?

With FW V1.15.0 I get the same behavior as you, that it randomly stop working. I've also tried the V1.16.0 FW and there I get that behavior after 3 file openings.

/Dejan

Hello @Dejan Nedeljkovic​ - did you try my solution to fix it?

But it sounds like a slightly different behavior - my problem was the initial mount of the SD card while yours sound like it stops working after it was opened.

Hi @MBabu.1​ 

Your solution worked with the V1.15.0 FW. Thank you for that.

I could not get it working with any workaround on the V1.16.0 FW.

So I will stick to the V1.15.0

What FW did you use for your testing?

/Dejan

What firmware version are you talking about?

STM32 HAL: V1.7.10

FatFS: R0.12c

CMSIS: V2.6.5

If it is actually working with V1.15.0 but not with V1.16.0 anymore, that strongly smells like a software regression. I recommend you to open a new Issue about that and referencing this one so ST will notice about that. Or maybe even contact ST directly.