We noticed that there is a race condition in the function HAL_QSPI_Transmit_DMA in the following code:
/* Enable the QSPI transmit MDMA */
if (HAL_MDMA_Start_IT(hqspi->hmdma, (uint32_t)pData, (uint32_t)&hqspi->Instance->DR, hqspi->TxXferSize, 1) == HAL_OK)
{
/* Process unlocked */
__HAL_UNLOCK(hqspi);
/* Enable the QSPI transfer error Interrupt */
__HAL_QSPI_ENABLE_IT(hqspi, QSPI_IT_TE);
/* Enable using MDMA by setting DMAEN, note that DMAEN bit is "reserved"
but no impact on H7 HW and it minimize the cost in the footprint */
SET_BIT(hqspi->Instance->CR, QUADSPI_CR_DMAEN);
}
The line HAL_MDMA_Start_IT starts the DMA which loads data into the QSPI FIFO. Depending on the amount of data this could be very quick. Once DMA has finished it triggers the interrupt MDMA_IRQHandler -> HAL_MDMA_IRQHandler -> XferBufferCpltCallback -> QSPI_DMATxCplt which enables the QSPI transfer complete Interrupt via
__HAL_QSPI_ENABLE_IT(hqspi, QSPI_IT_TC);
As this a read-modify-write operation it is racing with the enabling of the QSPI transfer error interrupt (QSPI_IT_TE) and setting of the QUADSPI_CR_DMAEN bit.
The workaround we are using is to disable interrupts for the duration of the call to HAL_QSPI_Transmit_DMA.
Thanks for fixing this in the next version.
