We are using an STM32L452, running directly from an HSE crystal at 8 MHz (i.e. no PLL), using the SDMMC peripheral with an SD clock of 8 MHz, and DMA for transferring data to and from SDMMC.
HAL_SD_IRQHandler() relies on the value of hsd->Context to determine which actions to take, rather than on, say, the value of CMDINDEX or RESPCMD.
Unfortunately, SD_DMAReceiveCplt() - called from the DMA interrupt - modifies hsd->Context, and as reported in another bug report, it's possible for the DMA interrupt to trigger before the SD interrupt, meaning that the value of Context will be wrong, and hence the SD interrupt will execute the wrong action.
We found that this could be avoided by instead checking CMDINDEX (in register SDMMC_CMD) to see which command was last issued. This eliminated this race condition.
Similarly, SD_DMAReceiveCplt() is also dependent on hsd->Context, which means that if the SD interrupt fires first and changes Context, the function may take the wrong action. As mentioned in the other bug report, we found that this could be avoided by only calling callbacks after both interrupts have completed.
During this investigation, we also learnt the importance of ensuring that the SD and DMA interrupts have the same interrupt priority, so that it is impossible for either one to interrupt the other. We would recommend that Cube enforce this.
