當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

STM32的串口函数_库函数USART_SendData问题和解决方法--硬件复位导致第一个字节丢失

發布時間：2025/4/16 编程问答 69 豆豆

生活随笔收集整理的這篇文章主要介紹了 STM32的串口函数_库函数USART_SendData问题和解决方法--硬件复位导致第一个字节丢失小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

本文轉自：http://blog.sina.com.cn/s/blog_717116870102vb4c.html

個人記錄：

昨天做串口實驗的時候一直沒有成功的原因，連續調用USART_SendData總是會出現前一個被后一個覆蓋的情況。之前覺得ST的官方庫應該沒有問題就沒往這方面想，現在查查，確實有庫的問題，還是自己對庫不太理解。
還有遇到的硬件復位以后，發送第一個字符丟失的情況。
1、后字節覆蓋前字節 ? -----------------加判斷while(USART_GetFlagStatus(USARTx, USART_FLAG_TXE) == RESET){}? 2、硬件復位之后第一個字符丟失 -----------------USART_ClearFlag(USART2,USART_FLAG_TC); -----------------USART_SendData(USART2,0x01);

-----------------while(USART_GetFlagStatus(USART2,USART_FLAG_TC)==RESET);

轉載正文：

1. 問題及現象

使用USART_SendData()函數非連續發送單個字符是沒有問題的；當連續發送字符時(兩個字符間沒有延時)，就會發現發送緩沖區有溢出現象。若發送的數據量很小時，此時串口發送的只是最后一個字符，當發送數據量大時，就會導致發送的數據莫名其妙的丟失。

如：

1 2	for(TxCounter= 0;TxCounter < RxCounter; TxCounter++) USART_SendData(USART1, RxBuffer[TxCounter]);

2. 原因

此API函數不完善，函數體內部沒有一個判斷一個字符是否發送完畢的語句，而是把數據直接放入發送緩沖區，當連續發送數據時，由于發送移位寄存器的速度限制（與通信波特率有關），導致發送緩沖區的數據溢出，老的數據還未及時發送出去，新的數據又把發送緩沖區的老數據覆蓋了。

3. 解決方法

發送后等待一段時間延遲的方法就不說了，等待時間不確定，此為下下策。提供下面2種方案：

方案1. 在每一個字符發送后檢測狀態位

USART_SendData(USART1, RxBuffer[TxCounter]);

while(USART_GetFlagStatus(USARTx, USART_FLAG_TXE) == RESET){} //等待發送緩沖區空才能發送下一個字符

方案2. 修改庫函數

修改USART_SendData()函數，在其內部加入發送緩沖區的USART_FLAG_TXE狀態檢測語句，確保一個字符完全發送出去，才進行下一個字符的發送。

實現方法：每發送一個字符都檢測狀態寄存器，確保數據已經發送完畢。具體操作步驟如下所示。

修改前的函數定義體

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 

   void  USART_SendData(USART_TypeDef* USARTx, u16 Data)  {  assert_param(IS_USART_ALL_PERIPH(USARTx));  assert_param(IS_USART_DATA(Data));  USARTx->DR = (Data & (u16)0x01FF);  }  

修改后的函數定義體

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 

   void  USART_SendData(USART_TypeDef* USARTx, u16 Data)  {  assert_param(IS_USART_ALL_PERIPH(USARTx));  
   assert_param(IS_USART_DATA(Data));  USARTx->DR = (Data & (u16)0x01FF);  while(USART_GetFlagStatus(USARTx,USART_FLAG_TXE) == RESET){}  //等待發送緩沖區空才能發送下一個字符  }  可能有人認為，為什么不預先在庫函數中處理這個問題，而把解決方法拋給用戶。個人認為ST這么做的原因是：使用發送中斷功能。  

4.?TXE和TC標志位詳細說明

在USART的發送端有2個寄存器，一個是程序可以看到的USART_DR寄存器(下圖中陰影部分的TDR)，另一個是程序看不到的移位寄存器(下圖中陰影部分Transmit Shift Register)。

對應USART數據發送有兩個標志，一個是TXE=發送數據寄存器空，另一個是TC=發送結束；對照下圖，當TDR中的數據傳送到移位寄存器后，TXE被設置，此時移位寄存器開始向TX信號線按位傳輸數據，但因為TDR已經變空，程序可以把下一個要發送的字節(操作USART_DR)寫入TDR中，而不必等到移位寄存器中所有位發送結束，所有位發送結束時(送出停止位后)硬件會設置TC標志。

另一方面，在剛剛初始化好USART還沒有發送任何數據時，也會有TXE標志，因為這時發送數據寄存器是空的。

TXEIE和TCIE的意義很簡單，TXEIE允許在TXE標志為'1'時產生中斷，而TCIE允許在TC標志為'1'時產生中斷。

至于什么時候使用哪個標志，需要根據你的需要自己決定。但我認為TXE允許程序有更充裕的時間填寫TDR寄存器，保證發送的數據流不間斷。TC可以讓程序知道發送結束的確切時間，有利于程序控制外部數據流的時序。

下圖是STM32技術參考手冊中的一頁：

轉載正文2

stm32 串口發送數據第一字節丟失

使用stm32f10x調試串口通訊時，發現一個出錯的現象，硬件復位重啟之后，發送測試數據0x01 0x02 0x03 0x04..接收端收到的數據為：0x02 0x03 0x04，第一個數據丟失。

查閱stm32f10x參考手冊，找到這樣一句話：?
TC：發送完成?
當包含有數據的一幀發送完成后，由硬件將該位置位。如果USART_CR1中的TCIE為1，則產生中斷。由軟件序列清除該位(先讀USART_SR，然后寫入USART_DR)。TC位也可以通過寫入0來清除，只有在多緩存通訊中才推薦這種清除程序。?
0：發送還未完成；?
1：發送完成。?
注意到這一句：由軟件序列清除該位(先讀USART_SR，然后寫入USART_DR)。也就是說，要先read USART_SR,然后write USART_DR，才能完成TC狀態位的清除。而硬件復位后，串口發送的首個數據之前沒有read SR的操作，是直接write DR，也就是說，TC沒有被清除掉。?

????硬件復位后，串口發送首個數據之前，先讀取一下USART_SR，則能夠保證首個數據發送時，不出現覆蓋的情況。當然，也有別的方法，比如先清除TC狀態位，USART_ClearFlag(USART1, USART_FLAG_TC);或USART1->SR&=~(1<<7);

轉載正文3

stm32串口第一字節丟失問題分析

STM32串口發送必須先檢測狀態，否則第一個字節無法發出，發送完畢，必須檢測發送狀態是否完成，否則，發送不成功，

使用stm32f10x調試串口通訊時，發現一個出錯的現象，硬件復位重啟之后，發送測試數據0x010x020x030x04..接收端收到的數據為：0x020x030x04，第一個數據丟失。換成發送別的數值的數據，如0x060x0ff，則接收到0x0ff，0x06丟失。錯誤依舊。

故障排除過程：

1、剛開始懷疑是接收端的錯誤，我是使用電腦串口，運行串口輔助調試工具接收，換成其他軟件后，發現故障依舊，而且電腦軟件一直是開啟狀態，不像和電腦軟件有關。

2、使用單步調試，單步運行各個發送指令，都正常。能收到0x010x020x030x04的數據。間接的排除了不是電腦軟件的問題，而是其他的錯誤。

3、單步調試運行雖然正常了，但連續運行時，錯誤依舊。現在有點摸不到頭緒了，單步運行正常，看起來編程沒有出錯，那故障在哪里呢？測試程序如下

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、猜測，也許是因為某個特殊原因，使第二個數據覆蓋了首個數據，使得首個數據丟失。假設：在執行B指令時，USART的TC狀態位==SET，那么就會緊接著執行C指令，也就有可能發生數據的覆蓋。于是，在A指令前，加入如下指令：USART_ClearFlag(USART2,USART_FLAG_TC);

5、加入上一條指令后，運行，錯誤消失了。說明上一個假設，應該是成立的。

6、查閱stm32f10x參考手冊，找到這樣一句話：TC：發送完成

當包含有數據的一幀發送完成后，由硬件將該位置位。如果USART_CR1中的TCIE為1，則產生中斷。由軟件序列清除該位(先讀USART_SR，然后寫入USART_DR)。TC位也可以通過寫入0來清除，只有在多緩存通訊中才推薦這種清除程序。0：發送還未完成；1：發送完成。

7、注意到這一句：由軟件序列清除該位(先讀USART_SR，然后寫入USART_DR)。也就是說，要先readUSART_SR,然后writeUSART_DR，才能完成TC狀態位的清除。而硬件復位后，串口發送的首個數據之前沒有readSR的操作，是直接writeDR，也就是說，TC沒有被清除掉。說明第4步的猜測是對的。

8、那么，應該把指令A前面加的USART_ClearFlag(USART2,USART_FLAG_TC);改為USART_GetFlagStatus(USART2,USART_FLAG_TC);，應該也能消除錯誤。測試后證實，確實如此，在發送首個數據之前，先讀取一下USART_SR，那么就不會出現首個數據丟失的情況了。

9、總結：硬件復位后，串口發送首個數據之前，先讀取一下USART_SR，則能夠保證首個數據發送時，不出現覆蓋的情況。當然，也有別的方法，比如先清除TC狀態位，或是，在writeUSART_DR之后，加入一個小延時，讓數據發送完畢，應該也能間接排除這個錯誤。