Hello,
I am using a Riverdi RVT101HVSNWC00 board (with STM32H757) for a product that needs a display, interfaces to devices, and writes data to a microSD card. After communicating with Riverdi, I gathered the correct SDMMC1 configuration to make the peripheral work and allow the Cortex-M7 core to write data to the filesystem on the SD card. M7 is completely functional with the SD card. However, the software architecture I would like to implement requires that the Cortex-M4 core be responsible for the SD card. I cannot get the M4 to even initialize the SDMMC1 peripheral no matter what I do.
I have SDMMC1 enabled for only the M4 core in CubeMX, with the correct peripheral, DMA, and FatFs configuration. When M4 calls MX_SDMMC1_SD_Init(), execution eventually comes to HAL_SD_InitCard() in stm32h7xx_hal_sd.c. This then calls HAL_RCCEx_GetPeriphCLKFreq(RCC_PERIPHCLK_SDMMC), which returns 0 because HAL_IS_BIT_SET(RCC->CR, RCC_CR_PLL1RDY) returns false (bit not set) at stm32h7xx_hal_rcc_ex.c line 2717 (firmware version V1.11.2). The HAL sees this zero return value and assumes something is wrong with the peripheral clock, and refuses to proceed with peripheral/card initialization.
This is of course incorrect, as I have SYSCLK fed from PLL1P and the system is stable, and SDMMC1 fed from PLL1Q and it also works with M7. With GDB I can read the RCC_CR register from both M7 and M4 perspective, and I see that on M7 it shows the PLLs as ready (RDY bits set), while on M4 those bits are clear.
What could be causing this? I read through some of the RCC section of the reference manual and it appears that the two cores have different access to RCC registers (but only sometimes...calling __HAL_RCC_SDMMC1_CLK_ENABLE() on M4 before it calls MX_SDMMC1_SD_Init() makes no difference).
I have tried fiddling with SDMMC1 clocks and modes to no avail. I also checked the errata sheet but there's no information about this in there. I assume that this is a software bug somewhere, probably in my configuration.
