There's a serious bug in G4's hal(version 1.6.1) library in spi dma function.
The problem is:
1, user calls HAL_SPI_TransmitReceive_DMA
2, after spi transmission finished, HAL will call HAL_SPI_TxRxCpltCallback
3, user calls HAL_SPI_Receive_DMA inside HAL_SPI_TxRxCpltCallback, and will fail in a chance.
The reason is:
1, HAL_SPI_TransmitReceive_DMA will start both Rx and Tx dma, and after transmission complete, HAL_DMA_IRQHandler will be triggered to set dma handler's state to ready and unlock dma handler;
2, If Rx dma complete first and trigger HAL_SPI_TxRxCpltCallback, user calls HAL_SPI_Receive_DMA in the callback, don't know why HAL will still start Tx dma which is still locked, that cause function to fail.
3, if Tx dma complete first, the scenario above will be fine. Unfortunately, these 2 simultaneously started dma(Rx & Tx) seem to complete in a random sequence (most of time Tx dma complete first) in my observation, in a rare case Rx dma will complete first which cause application to fail.
4, I compared with H7's HAL in HAL_SPI_Receive_DMA it only start Rx dma, that's why the same program runs ok in H7 platform.
The Workaround is:
add 2 lines below in HAL_SPI_TxRxCpltCallback:
__HAL_UNLOCK(hspi->hdmatx);
hspi->hdmatx->State = HAL_DMA_STATE_READY;
P.S.
If anyone recall I reported this porblem in a few month ago, at that time I just notice compile hal_dma.c as o1 will be somehow better, but unfortunately it's not the real cause.
STM32G4 HAL DMA start failed after software reset ... - STMicroelectronics Community
