Skip to main content
Associate II
August 23, 2025
Question

Bug in SPI DMA functions in HAL (1.6.1) of STM32G4 ?

  • August 23, 2025
  • 2 replies
  • 875 views

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

2 replies

Technical Moderator
August 25, 2025

Hello @TomZhu 

Thank you for bringing this issue to our attention.

I reported this internally for HAL version 1.2.5.

Internal ticket number: 216230 (This is an internal tracking number and is not accessible or usable by customers).

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
TomZhuAuthor
Associate II
August 27, 2025

Hi @Saket_Om

Sorry I'm using HAL version STM32Cube_FW_G4_V1.6.1. In the main thread I mixed up HAL version with DFP version.

Technical Moderator
August 27, 2025

Hello @TomZhu 

Have you tried setting the TX DMA interrupt priority higher than the RX DMA interrupt priority?

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
Andrew Neil
Super User
August 27, 2025

@TomZhu wrote:

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.


Why calling Receive in the callback? 

Doesn't, TransmitReceive do both the transmit and the receive?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
TomZhuAuthor
Associate II
August 28, 2025

Hi @Andrew Neil 

To drive a populer imu sensor ICM-42688-P, we need first to read(using TransmitReceive function) its FIFO_COUNT register to determine how many bytes in its FIFO port, then generate SPI clocks(using Receive function) accordingly.

So the complete read behavior contains 2 phases, it's no matter the second phase using TransmitReceive or just Receive function, the important is first phase clock is predetermined(read FIFO_COUNT register), and the second phase clock is depending on the first phase result.