STM32F413 - Delay at the end of UART transmit

[jonathanb]

Hello,

I am encountering an issue with the STM32F413 MCU: when transmitting data over UART, there is a short delay between the stop bit of one byte and the start bit of the next byte when transmitting data one byte at a time.

I compared the behavior of this chip with that of the STM32H743, which does not produce the extra bit.

The first image shows the timing when repeatedly transmitting the byte 0x0F at 9600 baud with 1 stop bit and no parity on the STM32H743 Nucleo board. Each byte is the expected size of ~1ms

The image below is the same code running on the STMF413 Nucleo board with the same settings. The extra time can be seen at the end of each stop bit.

For both boards I generated code using STM32CubeMX with UART 2 enabled and added the following code in the main function:

uint8_t data = 0x0F;
 
while(true)
{
    HAL_UART_Transmit(&huart2, &data, 1, HAL_MAX_DELAY);
}

Any insight on why this behaviour is occurring? And are there any MCUs similar to the F413 that are known to not have this problem?

[waclawek.jan]

Don't transmit one by one, or don't use the Cube function which (quite correctly) waits until the last byte leaves the shift register.

JW

[Paul1]

What function would avoid the extra bit time when you have to send byte by byte?

Are there any similar STM32 that don't do this? (something smaller and lower power than the STM32H743)

I've seen the extra "bit" also at the end of packets when using HAL_UART_Transmit(), which can cause issues when using Transmit Enable on RS-485, as the extra bit affects Data Enable operation which causes clash with the start bit of other boards/modules.

Paul

[TDK]

What JW is suggesting is to still use HAL_UART_Transmit but with more than one byte at a time. This is not a hardware limitation. It is a result of the software and how you’re using it.

If you need tight, non-standard uart timing, you’ll probably need your own driver.

[waclawek.jan]

>What function would avoid the extra bit time when you have to send byte by byte?

Function written by you.

It's trivial to write. Wait until UARTx_SR.TXE is set, then write the byte into UARTx_DR.

For 485 steering, in 'F4 you'd need to wait for TXC be set after the last byte (after having cleared it before). Newer families such as 'F0 have an option to generate DE in hardware. Read the RM.

JW

[jonathanb]

Comparing the HAL_UART_Transmit() functions of the f4 and the h7 HAL libraries, they both wait for the TC flag after all bytes are sent

if (UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_TC, RESET, tickstart, Timeout) != HAL_OK)
    {
      return HAL_TIMEOUT;
    }

so why does the extra delay occur with the f413 but not the h743?

[waclawek.jan]

Because the F4 is slower? Or the code is compiled with different settings? Our there are two stopbits set? My crystal cube is not sure.

JW