Several common reasons for serial port data loss

The serial port is one of the most commonly used serial peripherals by engineers, but in practical applications, various problems are often encountered, such as losing one byte of data.

Today, we will talk about UART related content in conjunction with STM32, and the problem of easily losing one byte of data.

Several UART flags

Here we focus on several flag bits in the UART status register: TXE, TC, RXNE, ORE.

These flags are often used in programming. Students who use the function library directly may not have paid attention to these flags. Data loss may be caused by improper operation of them, resulting in errors.

TXE: Transmit data register empty (Transmit data register empty)

  • 0: Data is not transferred to the shift register

  • 1: Data is transferred to the shift register

TC: Transmission complete

  • 0: Transmission not completed

  • 1: Transmission completed

RXNE: Read data register not empty (Read data register not empty)

  • 0: No data received

  • 1: Ready to read received data

ORE: Overrun error

  • 0: No overflow error

  • 1: Overflow error detected

UART communication hardware interface

Common UART communication hardware interfaces include: TTL, RS232, and RS485.

When programming, you need to consider the communication interface method. When communicating over long distances, you need to consider the delay on the line. Improper operation will also lead to data loss.

1. TTL

TTL is relatively simple, it is directly connected to the Tx and Rx pins of UART without external conversion. As shown in the picture:

Note: Tx and Rx pins need to be cross-connected.

2. RS232

The RS-232 standard interface is one of the commonly used serial communication interface standards. It stipulates that the level of logic "1" is -5V~-15V, and the level of logic "0" is +5V~+15V.

The purpose of selecting this electrical standard is to improve the anti-interference ability and increase the communication distance.

3. RS485

RS485 generally uses a two-wire wiring method. This wiring method is a bus topology, and multiple nodes can be connected to the same bus.

In low-speed, short-distance, interference-free situations, ordinary twisted pairs can be used; conversely, in high-speed, long-term transmission, special RS485 cables with impedance matching (generally 120Ω) must be used; in environments with severe interference, Armored twisted-pair shielded cables should be used.

UART receives lost data

The loss of data received by UART may be related to both software and hardware. Here are some common causes and solutions of lost data.

1. Receive data lost due to overflow

It refers to the loss of data due to overflow errors caused by failure to remove data in time. This usually occurs when a large amount of data is received in a query mode. Data loss may occur during the MCU startup process, too much received data is not processed in time, or complex systems do not respond in a timely manner.

Solution:

  • Clear overflow error flags promptly

  • Leverage communication protocols to filter problems caused by data loss

2. Loss of data due to receive interruption

It is more common to use UART interrupt to receive data than the query method to receive data. The interrupt method responds more promptly than the query method, but unreasonable processing will also cause data loss.

When the amount of data is large, the UART reception interrupt function is time-consuming and has low priority, and data is easily lost.

Solution:

  • Reduce unnecessary time-consuming in interrupt functions

  • Reasonably allocate interrupt priorities

  • Clear flag bit before enabling interrupt

3. Clock error leads to data loss

When the communication baud rate is high, if the clock error increases, data loss is likely to occur.

Solution:

  • Use higher precision crystal oscillator

  • Reduce communication baud rate

UART sends lost data

Many engineers have encountered loss of data sent by UART, usually because the transmission is not completed.

The HAL library has been around for several years, but many engineers still use the standard peripheral library. At this time, if the interface is not encapsulated properly, there will be a problem of losing the last byte of data sent.

1. Data loss due to incomplete UART transmission

The following code only considers non-empty data, but the actual transmission is not completed.

void UART_SendByte(uint8_t Data){ while(RESET == USART_GetFlagStatus(USART1, USART_FLAG_TXE)); USART_SendData(USART1, Data);}

However, sending non-empty data does not mean that the sending is completed. Although it is more efficient in some situations, it may lead to data loss in some situations.

For example: use this function to enter sleep after sending, turn off the power of the receiving device, etc.

Solution:

  • Wait for sending to complete

void UART_SendByte(uint8_t Data){ while(RESET == USART_GetFlagStatus(USART1, USART_FLAG_TXE)); USART_SendData(USART1, Data); while(RESET == USART_GetFlagStatus(USART1, USART_FLAG_TC));}

If you use the standard peripheral library, you need to encapsulate functions according to the actual situation, such as sending timeout.

Or use the HAL encapsulated interface, and the code includes judging that the transmission is completed:

HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)

2. Line delay leads to data loss

UART usually uses 232 or 485 to increase the transmission distance and enhance interference. However, once the data line is too long, there will be a transmission delay, especially when 485 transmits over long distances and uses an MCU to control the transmission direction.

Solution:

  • Software adds delay processing

  • Use communication protocols to add response mechanisms

3. Other reasons

There are many UART application scenarios. Some applications are in complex factories, where interference is large, leading to data loss; some applications are in environments with large temperature differences, where clock offsets are large, leading to data loss.

The solution needs to be based on the actual situation and solve the problem in a targeted manner. For example: use better communication lines, make software fault-tolerant, etc.

Sourcing: strongerHuang

Back to Lisa's Column