STM32Cube_FW_H7_V1.11.0
I am not using the STM32H735G-DK example for the discovery board, but ported it to use on the STM32H743-eval board and found that during initialization of the fx thread an attempt is made to open the SD card. There are actually two problems with the way it is done. 1) Not really a bug, the thread tries to open the card without checking if it is present, and will fail if it is not and there is no recovery; 2) The bug is where the thread ends up calling into the HAL layer using stm32h7xx_hal_sd.c, HAL_SD_InitCard(). This is bad because AzRTOS is now running and the HAL layer does not check for running threads. In the named function, somewhere after line 516, to allow time after the SDMMC_PowerState_ON() for the SD card to stabilize, the code calls HAL_Delay(). This will likely hang, since at this point the HAL tick is no longer ticking. Not withstanding the equation to formulate the delay is absurd. I wrote about this in another post telling that unless the SD card was operating below 1000 Hz clock speed the delay calculated will always be one which would make a 1ms delay plus overhead yielding a 400 cycle delay for the SD card. This is much more than the 74 cycles at 400000 Hz needed. So why the do the calculation? But I digress.
So this is what I did to fix it:
1) comment out the HAL_Delay
2) replace it with a fixed loop software delay calculated from the HCLK:
if (sdmmc_clk != 0U)
{
sdmmc_clk = ((HAL_RCC_GetHCLKFreq() / sdmmc_clk) * 74) / 4 ;
//HAL_Delay(1U + (74U * 1000U / (sdmmc_clk)));
while(sdmmc_clk != 0){
sdmmc_clk -= 1;
}
}
I used a factor of 4 as a first attempt for the number of system clocks it takes to execute the while(). I am sure it is more than that but this WORKS!
The other solution is to replace the HAL_Delay with Threadx_sleep but then you need to waist time chceking for tread awareness and by that time the 74 cycles of 400KHz may be in the past.
