STM loses the first byte when sending continuously

When I was compiling the program, I encountered a problem: the output of this program should be 57H 53H 07H D0H , but the actual debugging output was 53H 07H D0H, and the first byte 57H was lost. In fact, before this, when I was debugging the formaldehyde sensor, I found that the first command sent to the formaldehyde sensor failed. I naively thought it was a problem with the sensor and did not respond effectively to the command I sent. However, today's phenomenon shows that the serial port of the microcontroller failed to send out the first byte. So, I used Baidu and found the following excerpt: ———————————————————————————————————————————————— ———————————————————————————————————————————————— STM32 serial port transmission must first detect the status, otherwise the first byte cannot be sent. After sending, it is necessary to detect whether the sending status is completed, otherwise, the transmission is unsuccessful. When using stm32f10x to debug serial port communication, an error phenomenon is found. After hardware reset and restart, the test data 0x01 0x02 0x03 0x04 is sent.. The data received by the receiving end is: 0x02 0x03 0x04, and the first data is lost. Change to send data with other values, such as 0x06 0x0ff, then 0x0ff is received, and 0x06 is lost. The error remains.     Troubleshooting process:     1. At first, I suspected that it was an error on the receiving end. I used the computer serial port and ran the serial port auxiliary debugging tool to receive. After changing to other software, I found that the fault still existed, and the computer software was always in the open state, which did not seem to be related to the computer software.     2. Using single-step debugging, single-step running of each sending instruction, all normal. Can receive data 0x01 0x02 0x03 0x04. Indirectly ruled out that it was not a problem with the computer software, but other errors.     3. Although the single-step debugging runs normally, the error still exists when running continuously. Now I am a little confused. The single-step running is normal, and it seems that there is no error in the programming. So where is the fault? The test program is as follows    USART_SendData(USART2, 0x01); //A    while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET); //B    USART_SendData(USART2, 0x02); //C    while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET);    USART_SendData(USART2, 0x03);    while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET);    USART_SendData(USART2, 0x04);    while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET);     4. Guess that maybe it is because of some special reason that the second data overwrites the first data, causing the first data to be lost. Assumption: When executing instruction B, the TC status bit of USART == SET, then instruction C will be executed immediately, and data overwriting may occur. Therefore, before instruction A, add the following instruction:    USART_ClearFlag(USART2,USART_FLAG_TC);     5. After adding the previous instruction, run and the error disappears. This shows that the previous assumption should be true.     6. Check the stm32f10x reference manual and find the following sentence: TC: Transmission completed When a frame containing data is transmitted, the hardware sets this bit. If TCIE in USART_CR1 is 1, an interrupt is generated. The bit is cleared by the software sequence (read USART_SR first, then write USART_DR). The TC bit can also be cleared by writing 0, and this clearing procedure is only recommended in multi-buffer communication. 0: Transmission is not yet completed; 1: Transmission is completed.     7. Note this sentence: The bit is cleared by the software sequence (read USART_SR first, then write USART_DR). In other words, you must first read USART_SR, then write USART_DR to complete the clearing of the TC status bit. After the hardware reset, the first data sent by the serial port is written to DR directly without the read SR operation, that is, TC is not cleared. This means that the guess in step 4 is correct.     8. Then, the USART_ClearFlag(USART2,USART_FLAG_TC); added in front of instruction A should be changed to USART_GetFlagStatus(USART2, USART_FLAG_TC);, which should also eliminate the error. After testing, it is confirmed that this is indeed the case. Before sending the first data, read USART_SR first, then the first data will not be lost.     9. Summary: After the hardware reset, read USART_SR before sending the first data of the serial port, which can ensure that there is no overwriting when the first data is sent. Of course, there are other methods, such as clearing the TC status bit first, or adding a small delay after writing USART_DR to allow the data to be sent, which should also indirectly eliminate this error. —————————————————————————————————————————————————— —————————————————————————————————————————————————— Inspired by this article, I did the following operations. According to the tips in Articles 7 and 8, I read USART_SR before sending the first byte. I put this operation in the serial port initialization, so that it is not necessary to perform this operation in each byte sending function, and it is enough to solve the first byte after initialization. As shown in the figure below. This solved the problem.