SDCard FR_NOT_READY after migrating from FW_F4 V1.27.0 to V1.27.1

[DDi S.1]

As I wrote in the subject, Upgrading STM32CubeMX from version 6.6.1 to 6.7.0 The SDCARD stops working.

During mounting :

  fr=f_mount(&FatFs,"/",1);

  if(fr==FR_OK)

  {

    ...

   ....

 }

returns "FR_NOT_READY"

The micro is an STM32F4, I use SDIO in SD 4 bits Wide bus mode and it has always worked fine.

Regards

Domenico

[DDi S.1]

Hi,

After several hours of comparing the old and updated files I found a difference in the "sdio.c" file.

On line 47

old file: hsd.Init.BusWide = SDIO_BUS_WIDE_1B;

new file: hsd.Init.BusWide = SDIO_BUS_WIDE_4B;

by restoring this line the SDCARD works.

Considering that I have always used SDIO mode = "SD 4 bits Wide bus", I would like to understand if I have always worked on one bit or if on one bit it is just the initialization.

Regards

Domenico

[Amel NASRI]

Hi @DDi S.1​ ,

This is a similar issue as the one reported in problems with STM32F405 SD Card 4wiresCubeMX and SDMMC init error since STM32CubeIDE 1.11.0 update.

I let our STM32CubeMX expert @Semer CHERNI​ confirm about the status of this limitation.

-Amel

[Ghofrane GSOURI]

Hello @DDi S.1​ 

First let me thank you for posting

Actually there was a bug in the STM32CubeMX 6.6.1 concerning the SDIO : if you choose the SDIO mode SD 4 bits Wide bus the code generated is

static void MX_SDIO_SD_Init(void){

hsd.Init.BusWide = SDIO_BUS_WIDE_1B;

}

instead of

static void MX_SDIO_SD_Init(void){

hsd.Init.BusWide = SDIO_BUS_WIDE_4B;

}

This bug has been fixed in the latest version of STM32CubeMX 6.7.0

In your case that means that you used to work with SDIO_BUS_WIDE_1B instead of SDIO_BUS_WIDE_4B

In this situation you need to change your ioc configuration and choose the SDIO mode SD 1 bit Wide bus instead of 4 Bits wide (the easiest way to keep using your old project )

OR you change your code and take into consideration the 4 Bits wide SDIO

Thx

Ghofrane

[CKugl.1]

Ghofrane GSOURI (ST Employee) wrote:

...

> Actually there was a bug in the STM32CubeMX 6.6.1 concerning the SDIO : if you choose the SDIO mode SD 4 bits Wide bus the code generated is

>

> static void MX_SDIO_SD_Init(void){

>

> hsd.Init.BusWide = SDIO_BUS_WIDE_1B;

>

> }

>

> instead of

>

> static void MX_SDIO_SD_Init(void){

>

> hsd.Init.BusWide = SDIO_BUS_WIDE_4B;

>

> }

>

> This bug has been fixed in the latest version of STM32CubeMX 6.7.0

> ...

No, that change introduced a bug that broke working code. See STM32CubeMX 6.7.0 Breaks SD 4 Bits Wide Bus SDMMC on STM32L496xx STM32L4A6xx. Initialization must always take place in 1 bit wide mode. From the specification: "The default bus width after power up or GO_IDLE (CMD0) is 1 bit bus width."

[DDi S.1]

Hi,

I could be wrong, but I think the bug is just in the latest version.

Regardless of whether the bus is 1 or 4 bytes, I have found that the initialization of the SDCARD must always take place with a 1 byte bus.

regards

Domenico

[RRoss.6]

June 10, 2023, I am running STM32CubeIDE 1.12.1, with a Nucleo F767ZI, and I am seeing the same behavior (sort of). Inside MX_SDMMC1_SD_init() on this line:

hsd1.Init.BusWide = SDMMC_BUS_WIDE_4B ;

which is the autogenerated code, I have to change it to 1B to get things to work. Then it will only work the first time after a reset (and I also noticed that even with _1B set, later during initialization a call is made that changes things to 4 bit wide). If I remove the card and re-insert it, it fails on f_open() (although I'm not sure I am unmounting and mounting everything correctly when the card is removed and re-inserted - too tired, and I have spent WAYYYYY too much time on this already). All that to say, this SD Card stuff is all incredibly fragile. Would be nice if ST dedicated some resources to making this all work a little more reliably.

[Piranha]

> bus is 1 or 4 bytes

Bits not bytes! You have to understand what you are doing...

 

> All that to say, this SD Card stuff is all incredibly fragile.

https://community.st.com/s/question/0D53W00001JBTqKSAX/missing-dcache-clean-in-sddiskioc-sdread-causes-sd-card-fatfs-libraries-to-fail

 

[DiegoSF]

Same issue here.

Although in the HAL library (HAL_SD_InitCard function within stm32f4xx_hal_sd.c) initializes correctly to

Init.BusWide = SDIO_BUS_WIDE_1B) you need to make sure that in your main.c file it is also corrected within the SDIO Init function:

 

static void MX_SDIO_SD_Init(void)

{

 

/* USER CODE BEGIN SDIO_Init 0 */

 

/* USER CODE END SDIO_Init 0 */

 

/* USER CODE BEGIN SDIO_Init 1 */

 

/* USER CODE END SDIO_Init 1 */

hsd.Instance = SDIO;

hsd.Init.ClockEdge = SDIO_CLOCK_EDGE_RISING;

hsd.Init.ClockBypass = SDIO_CLOCK_BYPASS_DISABLE;

hsd.Init.ClockPowerSave = SDIO_CLOCK_POWER_SAVE_DISABLE;

hsd.Init.BusWide = SDIO_BUS_WIDE_4B;

hsd.Init.HardwareFlowControl = SDIO_HARDWARE_FLOW_CONTROL_DISABLE;

hsd.Init.ClockDiv = 24;

/* USER CODE BEGIN SDIO_Init 2 */

hsd.Init.BusWide = SDIO_BUS_WIDE_1B; //add this line, so that the automatic code generetation with STM32CubeIDE does not override the configuration

/* USER CODE END SDIO_Init 2 */

 

}

[brunob45]

Thank you!

static void MX_SDIO_SD_Init(void)
{
...
/* USER CODE BEGIN SDIO_Init 2 */
hsd.Init.BusWide = SDIO_BUS_WIDE_1B; //add this line, so that the automatic code generetation with STM32CubeIDE does not override the configuration
/* USER CODE END SDIO_Init 2 */
}

 

I confirm this also solves the SDIO issue with STM32F446RE, CubeMX 6.10.0 and STM32F4 package 1.28.0.

[TDK]

@Ghofrane GSOURI After the comments you received, are you still under the impression that this is not a bug? As has been explained, SD card must be initialized in 1 bit mode before switching to 4 bits. This is per the SD specification. Could we get it fixed?

10 months later.