STM32H7 CubeMX sdmmc clock not running

[GreenGuy]

Posted on July 11, 2018 at 22:34

Trying to replicate the functionality of the project example for FatFs_uSD_DMA_RTOS on the STM32H743I_Eval board using CubeMX I have run into the next layer of problems, this one involves the SDMMC clock.  There is none!

In the project example from the repository STM32Cube_FW_H7_V1.2.0, I noticed the initialization for the SDMMC clock is missing and yet the example works.  The PLL and bus clock dividers are setup but nothing is done for the peripheral clocks like what happens inside the CubeMX generated code.

So the question becomes what is the default state if no initialization is done for the peripheral clocks?  In particular, what happens to the SDMMC clock mux if PeriphClkInitStruct.PeriphClockSelection = ...|RCC_PERIPHCLK_SDMMC|... does not occur and no source is set like:

PeriphClkInitStruct.SdmmcClockSelection = RCC_SDMMCCLKSOURCE_PLL2;

which I copied from the CubeMX code?

I read somewhere else on the forum regarding PPL2 cannot be driving more than two destinations so I changed:

PeriphClkInitStruct.AdcClockSelection = RCC_ADCCLKSOURCE_PLL2;

to be :

PeriphClkInitStruct.AdcClockSelection = RCC_ADCCLKSOURCE_PLL3;

and now the code in the low level driver (stm32h7xx_ll_sdmmc.c) where the SDMMC_SendCommand is called completes with the command sent bit set (SDMMC_STAR = 0x80 - IAR) and the clock pin of the sdmmc is showing activity.  If both are set to PLL2 the SDMMC_SendCommand completes with the Hardware Status flag set meaning it is busy and the flag stays set.  On the next command to get the error state the operation times out which does not happen if PLL3 is used for the ADC.

The trouble I have with this behavior is something that Clive pointed out in another thread which is that CubeMX is very unclear in two regards.  1) CubeMX allows the errant selection when it clearly does not work, 2) The ADC mux selection indicates that PLL2P output is used and SDMMC mux indicates PLL2R output is used which can be interpreted as the sources are not exactly shared.  Or is there a typo in CubeMX and the ADC mux source is really PLL2R?

This all said the FatFs operations from the project example still do not work.  So I am on to the next layer.

And yes I using the latest CubeMX V26

[Tesla DeLorean]

Posted on July 12, 2018 at 01:14

By default it is the PLL1 Q Clock

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

 

I have a more elegant decoder for it now

    {

      int ck = SDMMC1-&gtCLKCR & 0x3FF      uint32_t sdmmc_ker_ck      if (__HAL_RCC_GET_SDMMC_SOURCE() == 0)      {        PLL1_ClocksTypeDef PLL1_Clocks        HAL_RCCEx_GetPLL1ClockFreq(&ampPLL1_Clocks)        sdmmc_ker_ck = PLL1_Clocks.PLL1_Q_Frequency      }      else      {        PLL2_ClocksTypeDef PLL2_Clocks        HAL_RCCEx_GetPLL2ClockFreq(&ampPLL2_Clocks)        sdmmc_ker_ck = PLL2_Clocks.PLL2_R_Frequency      }      printf(&39SDMMC_CK %4d, %6.2lf MHz\n&39, ck, ((double)sdmmc_ker_ck * 1e-6) / (double)(2.0 * ck))    }

[Tesla DeLorean]

Posted on July 12, 2018 at 01:25

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

 

Seemed to also remember Amel posting some patched code, might have been a different STM32 part, hard to keep track. If I find it I will post a link here.

Ok, here

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

 

[GreenGuy]

Posted on July 14, 2018 at 00:29

I applied the changes suggested by Amel N in

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

  and this changes the behavior where the SD clk is none existent when both ADC and SDMMC are set to PLL2.  However there is still problem where I am getting a disk error when I try to open the SDcard for read or mount with the force setting to 1.

[GreenGuy]

Posted on July 14, 2018 at 00:54

This is interesting.  The clock divider (CLKCR) remains 4 no matter what I set in MX_SDMMC1_SD_Init routine at the line

hsd1.Init.ClockDiv = 0;

The test was applied just before the mount call after the card has been initialized.  It is as if the CubeMX code is being ignored or stepped on.

[Amel NASRI · Accepted solution]

Hello,

Welcome in the new Community platform!

I would like to inform you that the RCC related issue is already fixed in current STM32CubeH7 package version (1.3.0).

The update is described as following in the release note file:

HAL RCC : Update and rework HAL_RCC_PeriphCLKConfig function in order to support consecutive configurations for several peripherals using PLL2 and PLL3. To do so first the given PLL is stopped, then the given divider is updated, the given PLL clock output divider is enabled and finally the given PLL is enabled.

Please try it and share your feedback if you still face any issue.

-Amel

[GreenGuy]

The V1.3.0 fixes this issue - Thanks to the team.

[GreenGuy]

There still a few remaining issues with generating a CubeMX project and the code work for FatFS. Do you want them listed here or in a new post. I had made a comprehensive post the day before the shutdown but I have not seen it restored.

[Tesla DeLorean]

They are still migrating some things, there are some message/post length issues.

Creating a PDF App Note might be the way to go.