Delay between UART TX frames at high speed

[LucaP]

I am sending a fixed-sized buffer (512 byte) at 8 Mbits/s via UART out of an STM32F3, and I am experiencing what it seems to be a fixed delay (~ 2-3 bit periods) between consecutive frames.

In the screenshot below, after sending the dummy value 01010101, it can be seen how the line idles high for quite a long time between the stop bit "1" of one frame and start bit "0" of the next. The bit period of ~125 ns is as expected and the data is received successfully by another STM32, but such a cumulative delay between frames (128 us min. over the entire buffer) is a problem for my application.

I have tried sending the buffer using HAL_Transmit, HAL_Transmit_DMA (single call) and a looped LL_USART_TransmitData8 (one byte at a time) with no apparent difference in results.

Any idea of what could I be doing wrong? Thanks!!!

[waclawek.jan]

> Any idea of what could I be doing wrong?

Yes. This:

> 8 Mbits/s via UART

UART is not meant to be a high-speed interface. You may be hitting some hardware limitation, either in the UART itself, or in the bus matrix.

JW

[LucaP]

I agree that I may be testing the UART limits, but with an fCLK = 72 MHz, the STM32F3 should be able to generate up to 9Mbps, according to the REF manual. In fact, at that speed the bit period gets as low as 110 ns (as expected).

However, at any baud rate above 6-7 Mbps, I notice that the frame rate no longer increases, i.e. the idling period kicks in and fills up the "dead time" until the next byte is ready to go out.

Still puzzled on where the culprit may be (albeit it may not be solvable)...

[Tesla DeLorean]

If the data flows constantly, perhaps use the DMA and HT/TC interrupts to prefill a circular buffer in a ping-pong fashion.

Or use the double-buffering methods

[GLASS]

Hi, if you get some delay between two byte during a single UART TX DMA, as stated by JW​, you may be hit bus contention. Try to manage bus priority, avoid other high bandwith DMA, try to reduce CPU activity, especially if it use the same RAM as the one used with our critical DMA.

On stm32f3 i remember that CCMRAM can be used for data and code but not for dma.

You can try to put data used only by CPU in CCMRAM, freeing DMA path to SRAM...

Also don't tx FLASH based data otherwise may be bus contention with instruction fetch​.