STM32H7 - UART DMA working only in debug mode

[Mdi c]

dear all, my STM32H7 based project implements three DMA streams, one for a SAI peripheral, a second one for the ADCs and the third one for UART comm.

static void MX_DMA_Init(void) 

{

 /* DMA controller clock enable */

 __HAL_RCC_DMA1_CLK_ENABLE();

 /* DMA interrupt init */

 /* DMA1_Stream0_IRQn interrupt configuration */

 HAL_NVIC_SetPriority(DMA1_Stream0_IRQn, 0, 0);

 HAL_NVIC_EnableIRQ(DMA1_Stream0_IRQn);

 /* DMA1_Stream1_IRQn interrupt configuration */

 HAL_NVIC_SetPriority(DMA1_Stream1_IRQn, 0, 0);

 HAL_NVIC_EnableIRQ(DMA1_Stream1_IRQn);

 /* DMA1_Stream2_IRQn interrupt configuration */

 HAL_NVIC_SetPriority(DMA1_Stream2_IRQn, 0, 0);

 HAL_NVIC_EnableIRQ(DMA1_Stream2_IRQn);

}

What I have noticed is that the UART interface works only when in debug mode. SAI and ADC instead work fine. Do you have any idea about where should I investigate the issue ? Thanks

[Danish1]

"not working" can describe a very large number of failure modes. Do you have any information as to *how* it doesn't work?

Is the UART for transmission or reception?

Is it possible for you to find out if your system thinks no characters have been received on the UART? Or maybe it thinks characters are coming in, but they aren't the ones you sent? Are you waiting for an interrupt saying "DMA complete" that never happens; once you have waited a reasonable time, can you peek the DMA registers and where the DMA was writing to, to see what, if anything, has happened?

In release mode, the build options tend to allow for optimisations where (for example) if a variable has already been read, the processor uses the already-read value rather than bothering to read it again. Which is fine unless something else changes it (e.g. the DMA, any other peripheral, or another thread in your code). The way to prevent this is to declare the variable "volatile".

And maybe your code also turns on the processor caches in release mode. Can you play around with settings between debug and release mode to discover which settings make your code not work?

A problem I hit going from the F4 to the F7 (so not as far as H7) was that writes to peripherals might get delayed in a write-back buffer, so I couldn't guarantee the order which things would happen unless I put in "DSB" (data-synchronisation barrier) instructions at key places in my code. This was only in low-level peripheral-setup code.

Is all of your UART use via the ST HAL libraries? I am not a fan of HAL because it hides understanding of what is going on, and thereby makes it harder to discover what's going wrong when things do go wrong.

Good luck in solving your problem; keep us informed of anything you discover,

Danish

[angrypotato]

Hi, I know its been a while, did you ever figure this out?

[Tesla DeLorean]

Present an actual problem, with actual information, and the problem might be solvable.

It's very hard to diagnose "not working" at a distance. You'll need to describe better what is and is not happening, what code you have running, and what the registers look like.