STMU5 GPDMA BNDT corrupted by suspend/resume

[PatrickM]

Hello,

I’ve run into what appears to be a documentation error or a H/W bug with the GPDMA on the STM32U585.

 

I’ve set up a 512-byte circular DMA buffer with HT and TC interrupts to capture UART Rx data.  I’ve also enbaled DTE and SUSP interupts because I want to handle UART IDLE detection.

 

In the UART IRQ handler (caused by IDLE), I suspend the DMA channel.  The DMA IRQ handler then triggers on SUSPF and I grab the current BNDT value, update an internal index, and then resume the DMA.  The DMA continues until the block is complete (TC), then reloads only the CxDAR from memory (only UDA set in CLLR update bits).  According to documentation, the BNDT value should be reloaded from an internal value stored when the channel was enabled.  This works as expected until the TC after suspend/resume event.  After a suspend/resume, the BNDT appears to reload a different value, and continues to use that new value.

 

The only work around I found was to add UB1 to the CLLR update bit fields and provide a corresponding UB1 in memory.

 

Can anyone verify if this is problem with documentation, or a H/W issue?

[PatrickM]

From further testing, only the first suspend/resume appears to change the internal BNDT value.  Subsequent suspend/resume cycles do not change the value from the previous “corrupted” value.

[PatrickM]

I have found why the BNDT value is changing on the first suspend/resume cycle.  In my ISR, when handling the SUSPF, I check if the channel is enabled, and if not, I “unsuspend” AND enable the channel.  The new BNDT value is latched at that point when I set the EN bit high.

 

What I still don’t understand is why the EN bit is low at that point.  Immediately before suspending the channel, I check the EN bit to ensure it is high (and hit a breakpoint if it is low).  The channel was enabled and active up until the channel was suspended.  It then became disabled between the suspend and checking the EN bit in the DMA Channel ISR.  On subsequent suspend/resumes, the EN remains high.

 

There were no errors (TOF, USEF, ULEF, DTEF), so I do not know how the channel EN bit could be cleared between the suspend and handling of the SUSPF.  I’m still investigating the cause.

 

 

[PatrickM]

I found the root cause.  There was an extra call to my DMA initialization routine which resets the DMA channel without checking the EN bit since it should only be called once out of reset.  The second call asserts the CCR Reset bit while the channel is enabled.  No errors are reported, and everything appears to work properly until the first suspend/resume cycle.

 

Adding a check for EN and waiting for channel to be idle before resetting appears to have fixed the problem.