Two UART interfaces via DMA fail in DEBUG mode

[mwhitecliff]

Hi

I have a custom board with STM32U575. It has two UART interfaces:

- UART1: Terminal interface (routed to the ST-Link header)

- UART3: Communication with additional MCU on the board

As the system is very busy, I implemented both UART to receive their data via DMA.

Now the questionable part:

In RELEASE build, the system works as expected. Both UART interface receives their data via DMA.

IN DEBUG mode, one interface does not work. I can control which interface will work and which not with the order of initialization of the two UART interfaces. It is always the latest which will work. I tracked it down and came to the conclusion, that the wrong error handler is called in case of an UART RX error (ORE)

The used DMA channels (changing the channels has no effect):

- UART1: GPDMA_Channel3

- UART3: GPDMA_Channel1

I set up the compiler flags and optimizations to the same for RELEASE and DEBUG mode to make sure this has no effect. The only difference I can now see is the defined "DEBUG" Symbol. First I tought it could be, that the SWD uses some DMA of my second UART interface. But as I changed the order of initialization of the UART interfaces I throw away this theory as the last one initialized always works.

What else could be different for the two modes? I could not track down any DEBUG preprocessor conditions in the stm32u5xx_hal_uart.c

 

Additional info (Edit):

In the `HAL_UART_IRQHandler`. At line 2431, after returning from the function (HAL_DMA_Abort_IT) returning HAL_OK, the `huart->ErrorCallback(huart);` is not called. Could this be a bug in the stm32u5xx_hal_uart.c? But why it works in RELEASE mode?

[waclawek.jan]

> I tracked it down and came to the conclusion, that the wrong error handler is called in case of an UART RX error (ORE)

What "wrong error handler"?

Isn't the problem simply that in DEBUG there's some other ISR which takes too long, UART overflows, and the overflow handling results in what you perceive as "does not work"?

If your mcu is that busy, you may want to consider to write your own UART handling rather than using Cube/HAL. I don't use Cube/HAL but if it uses the IDLE mechanism and single-shot DMA, it is not the best match to handle continuous UART stream or longer delays with disabled interrupts (other interrupts running). Or maybe just shuffling interrupt priorities might make a difference.

JW

[mwhitecliff]

Sorry, this was a mistake on my side. Not the wrong error handler is called. There is no error handler called if the DMA_Transfer is aborted. I think I have to follow your suggestion and implement my own UART handling.

[Karl Yamashita]

Post your code so we can see what you're doing.