Bug in GPDMA with 2D addressing (I think)

[FA1234]

I believe there's a bug in the stm32h7rsxx_hal_dma code for dealing with repeated blocks in interrupt mode. This bug probably exists in other STM32H7 devices as well.

With a typical repeating transfer, in *NON* interrupt mode, the DMA transfer completes successfully, and the DMA state ends up in HAL_DMA_STATE_READY, ready for another request. All is well.

However, in interrupt mode, the DMA transfer completes successfully (all data is correctly transferred), but querying the DMA state in the DMA Transfer Complete callback, you'll get HAL_DMA_STATE_BUSY. In fact, it will remain in this state forever.

Looking at the stm32h7rsxx_hal_dma.c code, the block starting at 1154 ("Transfer Complete Interrupt management"). There are really only two cases where the HAL_DMA_STATE_READY can be set:
1) LinkedList mode (not relevant to us)
2) "Normal transfer" where CBR1 == 0. (i.e. not a repeating block transfer) In a repeating transfer, CBR1 contains the repeating config, and is generally not 0 (it's called the "Alternate Block Register 1").

So, a repeating block transfer can seemingly never get back to HAL_DMA_STATE_READY with a repeating transfer.

You can reproduce this problem starting with the DMA_RepeatedBlock demo incremented gather operation. 

I'm not entirely sure of the fix here. Perhaps it's checking if we're in a repeating block transfer and assuming that's also a "normal transfer"?

[Saket_Om]

Hello @FA1234 

Thank you for bringing this issue to our attention.

I reported this internally.

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

[JDoe.2]

Hello @Saket_Om ,

Can you update us on this issue ? It's been five months. What's the hold-up ?

I'm trying to use GPDMA 2D addressing for sending a large amount of data from an array in SRAM to SPI and I face the same issues reported by @FA1234 

I have read every piece of documentation on the U5 family, erratas, app notes such as AN5593, etc... and I've watched every ST video on the GPDMA.

A prompt answer would be appreciated. I do not have 5 months to waste.

[FA1234]

v1.2 of the stm32h7rs HAL driver has come out in the last few months, but I do not see any changes to the DMA code which would resolve this problem.

In any case, setting the ConfigRepeatBlock before every DMA (and resetting the HAL_STATE_BUSY flag on dma_complete) was the fix that worked for me.

So, in my dma_complete_irq(DMA_HandleTypeDef* dmaHandle):

if (HAL_DMA_GetState(dmaHandle) == HAL_DMA_STATE_BUSY)
   dmaHandle->State = HAL_DMA_STATE_READY;

You could call HAL_DMAEx_ConfigRepeatBlock right here if you have it saved as a variable somewhere, or just call it next time you do a HAL_DMA_Start*().

Hopefully that'll get you unstuck, and hopefully ST is working on a fix for this.

 

[FA1234]

Some additional information of interest that maybe should be fixed as part of this issue (or at least documented).

The HAL_DMAEx_ConfigRepeatBlock() call that is added to the MX_HPDMA1_Init()/MX_GPDMA1_Init() function is *NOT* sticky. Meaning, you need to call this function before *every* DMA_Start_IT (and possibly DMA_Start) call. This is because the BNDT/BRC (meaning the repeat count and other config info) is decremented by the CPU as the block runs, eventually ending with it = 0. So, calling DMA_Start_IT() after that point is equivalent to starting with a non-repeating block request.

It seems possible that messing with the _CxLLR register could cause a situation where the CxBR1.BNDT/BRC will automatically reload with their programmed values, but it's not obvious which or even if this is possible.

So, my current hacked up solution is in the DMA transfer complete callback:

 

if (HAL_DMA_GetState(ptr) == HAL_DMA_STATE_BUSY) {
 ptr->State = HAL_DMA_STATE_READY; // Fix repeating DMA stuck in BUSY
 HAL_DMAEx_ConfigRepeatBlock(ptr, &repeatConfig); // Reset for next repeating DMA
}

 

 

[hartgordo]

Hi

For anyone having similar issues, here is the mod to the U5 library that worked for me:

in STM32Cube_FW_U5_V1.8.0 at STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_dma.c line 1073, in routine HAL_DMA_IRQHandler:

- if (hdma->Instance->CBR1 == 0U)
+ if ((hdma->Instance->CBR1&(DMA_CBR1_BNDT|DMA_CBR1_BRC)) == 0U)

Regards
GH