Bug report: STM32CubeMX 4.23 SD_initialize

[Hector Fernandez]

Posted on October 26, 2017 at 13:12

As I explaned in

https://community.st.com/0D50X00009XkXviSAF

, I have found another big error in the code generation of STM32CubeMX 4.23.

In this case, the bug is related to FATFS + SDMMC. In my case, I am working with an STM32F767 microcontroller.

I updated an old project to change some config settings, and when I regenerated the project files with STM32CubeMX 4.23, my SDMMC peripheral stopped working correctly. So far, it was working nice with the code generated by an older version of STM32CubeMX.

So, (thanks to GIT) I checked which files changed since last release, and I noticed that the problem was in 'SD_initialize' function in 'sd_diskio' file (inside Src folder).

The code that the newest version generates is:

DSTATUS SD_initialize(BYTE lun)

{

    return SD_CheckStatus(lun);

}

but, the same functions was different in my old code:

DSTATUS SD_initialize(BYTE lun)

{

   Stat = STA_NOINIT;

   /* Configure the uSD device */

   if(BSP_SD_Init() == MSD_OK)

   {

      Stat &= ~STA_NOINIT;

   }

   return Stat;

}

It is easy to understand that the difference between the new version and the old one is the lack of 

BSP_SD_Init(). This function isn't called in any other place but SD_initialize(). So, that is the reason because SDMMC stopped working.

Changing this piece of code in my new code solved all the problems and everything works as expected again.

Please, solve this bug in the next release. So far, I have found out 2 bugs in less than 2h. 

:crying_face:

[Amel NASRI]

Posted on October 26, 2017 at 18:49

Hi

fernandez.hector

‌,

I reported this issue to our CubeMX team to make required investigation and provide the fix.

Sorry for any inconvenience this created for you.

-Amel

[Mohammad A]

Posted on October 27, 2017 at 12:05

Here I have a similar problem, same Cubemx version, used for Cube F1 package.

This is what cubemx generates for SDIO initialization.

void MX_SDIO_SD_Init(void)
{
 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 = 0;
}�?�?�?�?�?�?�?�?�?�?�?�?

Actually doesn't do anything!

Took me a day to figure it out here. It's up to user to call HAL_SD_Init(&hsd); , otherwise nothing works!

[Stefan M�ller]

Posted on October 30, 2017 at 15:33

Hi, I had about the same issue, see here:

https://community.st.com/0D50X00009XkX6HSAV

I wonder if the user has a chance to modify the sd_dikio.c file before CubeMX uses it. As I'm just on the beginning of the project and step by step increasing Features it's a bit anoying to handleall this manually in the IDE as the files get overwritten each time you create new stuff byCubeMX.

@Mohammad: It's not the HAL_SD_Init, that's called by the BSP Driver. The reason is the SD_initialize not calling the BSP_SD_Init()

[dongdong chen]

Posted on November 10, 2017 at 09:14

Hi! I met this bug. It took me much time  to find the 

SD_initialize bug

:((

, but what's worse, i met other problem. When it ran to f_open() function, I met FR_DISK_ERR.I have 'park' here for almost two days. Anyone also? I need help.T.T 

[Stefan M�ller]

Posted on November 10, 2017 at 11:44

Hi,

f_mount success does not automatically mean your HW is working correctly. Follow the low level functions with the debugger and check if peripheral registers get correct values

[dongdong chen]

Posted on November 13, 2017 at 04:38

Oh�?Solved�?The reason is that the clock configuration is  incorrect.....

[Amel NASRI]

Posted on December 07, 2017 at 09:47

Hello,

For users facing similar issue, please refer to 

https://community.st.com/0D50X00009bMM8bSAG

 .

-Amel