UART with byte stream gets overrun error

[ranran]

Hello,

I worked till now with H7 (stm32h743) and UARTs and had no issues at all.

But recently I needed to port the project to L4 (stm32L496).

For some reason UART now behaves differently:

With polling there is no issue, but with interrupt or dma:

1. As long as I try to read into buffer the expected number of bytes it works well.
2. But if I do the receiving of bytes in slice (for example expecting 1024 bytes in slices of 64 bytes), I always get overrun error, even if I just doo HAL_delay(0), between each slice read.
3. I also get the same behavior when receiving bytes in DMA in circular mode.

The strange thing is that with H7 I never got this behaviour.

Is it related to cpu clock cycles , cache enable/disable , or some fifo which exist in H7 and doesn't exist in L4 ?

Thank you,

and wishing good health to anyone out there (or IN there) in ST community,

ranran

[Tesla DeLorean]

Would probably look to avoid delays in the interrupt or callback chains.

The HAL code is a bit convoluted and might have race hazards, if you can deal with the hardware at a register level it would be helpful. Try to avoid probing the UART in the debugger.

Check the interrupt priorities, and just how heavily loaded the high priority ones are, both in frequency, and work load.

Instrument with GPIO output so you can capture the failure on an analyzer.

Don't mention the L4 frequency, nor the bit/baud rates involved.

[KnarfB]

Thanks, same to you. You should check the reference manuals. If I remember correctly: H7 USARTs have a FIFO, L4 not. Look here for ideas: http://stm32f4-discovery.net/2017/07/stm32-tutorial-efficiently-receive-uart-data-using-dma/

[Tesla DeLorean]

As a technical note the L4+ have FIFO on some of the USARTs

[TDK · Accepted solution]

An overrun means you're not reading it fast enough. I don't find it strange that the H7's considerably more complex peripherals and faster clock speed behave differently than the L4.

> I always get overrun error, even if I just doo HAL_delay(0), between each slice read.

This causes a delay of between 0-1ms and can absolutely cause an overrun in itself. It's not a zero delay. Comment out the statement to remove the delay.