I try to use SDMMC1 on STM32H743I Nucleo: It works fine but just if I use PLL1: PeriphClkInitStruct.SdmmcClockSelection = RCC_SDMMCCLKSOURCE_PLL;
If I try to use PLL2, the PLL2R clock output via: PeriphClkInitStruct.SdmmcClockSelection = RCC_SDMMCCLKSOURCE_PLL2; it fails: there does not seem to be a clock for the SDMMC1 peripheral block: the state machine does not proceed, the very first command for PowerOn does not complete (times out) and the status register bit in STA for command complete is never set.
It looks like the PPL2R and RCC_SDMMCCLKSOURCE_PLL2 cannot be used, not working and SDMMC1 does not get a peripheral device clock. But PLL2 (PLL2P and PLL2Q) should be OK because I use for SPI peripherals and all fine.
Using FatFS on SD card needs careful handling of DCache. Even enabling the Cache Maintenance via macro ENABLE_SD_DMA_CACHE_MAINTENANCE=1 is not enough. All the SD card commands are working error free, the f_read() or f_write() functions return properly but the data buffers are not updated (and writes to SD card will corrupt file system).
The only solution was to setup also the MPU, for the SRAM region used for variables (RAM_D1, start address: 0x24000000), data structures and buffers related to the SD card functions. The MPU is configured for the RAM_D1 region as: MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE; - then it works.
Very strange: just DCache enabled but w/o related MPU entry fails, even with cache maintenance properly used.
it seems to me: if DCache is enabled - the MPU "must" be used and configured in order to specify the cache and buffer modes for the SRAM regions.
Be careful when using SDMMC1: I found a remark in an application note the SDMMC1 cannot access D2 SRAM.
And I have also realized that D2 SRAM (D2SRAM1, D2SRAM2, D2SRAM3) is not powered on, not enabled on reset and MCU startup. I had to enable those (via __HAL_RCC_D2SRAM1_CLK_ENABLE(); etc.) and it results in fact, that D2 SRAM cannot have initialized global variables (.data): they would not be loaded, not initialized by the debugger. Just during run time, after enabling D2 SRAM it can be used, but w/o to have it initialized (e.g. not filled with zero by startup).
The STM32H7 is a nice MCU but it seems to be a bit tricky, a bit "sensitive" in terms of clock configurations and when DCache is enabled (strange is also: if I just disable DCache, do not enable - my working project crashes now in a HardFaultHandler). My experience is: this H7 MCU is quite different, even if a similar project is working fine on an F7 MCU - you cannot really compare and use as a reference. You had to study carefully the H7 datasheet, "try this and that" and be aware of a quite different system architecture (e.g. how the DCache works, how to deal with the D1..D3 domains, memories and bus fabric = data paths).
==> what is your experience with this H7 MCU?