使用開發板的USART作為UART通信，在前調用BSP_Init（）函數初始化開發板，串口上傳輸的數據出錯：‘a’變成0xfa或0xfe;

【在這個問題解決之后，回頭總結下，在解決問題時：

1.預計有可能造成出錯的原因（這個可能需要一些經驗，但是思維方式需要這樣的猜測，從系統內外，可以先羅列出盡可能有的原因，后面再一一排除）

2.盡可能的定位出錯的地方（比如這里通過在線調試，確定在修改時鐘后，可以解決數據發送的不正確）

3.推測并排除次因，找出主因，往深一步探測 】

1：猜測原因。

外因：串口接收的過程受干擾

內因：A.端口設置有問題 B.USART的波特率設置有問題

2：定位錯誤

在剛開始時通過屏蔽BSP_Init（）發現功能正常，再具體定位到BSP_Init（）里面的SYSCLK_Frequency時鐘設置，發現例程中默認的是72M，但是改為36M，就沒有問題，應該是時鐘方面的設置問題，具體的問題做何解析？

3：推測排除，深究

外因內因很好排除，數據既然在波特率低時能正常通信，可能不是端口設置的問題，應該是波特率的問題，常看用戶手冊該節的資料：

注：

1.CPU 的時鐘頻率越低，則某一特定波特率的誤差也越低。可以達到的波特率上限可以由這組數據得到。

2.只有USART1 使用PCLK2（最高72MHz）。其它USART使用PCLK1（最高36MHz）。

USART的波特率的計算公式：

USARTDIV是一個無符號的定點數。這12位的值設置在USART_BRR寄存器。那么USARTDIV與USART_BRR的關系又是怎么樣的？

加入USARTDIV=27.75；那么USART_BRR=0x1B（27）+0XC（0.75*16）=0X1BC;同理可以從USART_BRR推出USARTDIV的值；

假設fck=36000000;Tx=115200;=》USARTDIV=19.53125;所以0x13+（0.53125*16=8.5）=》0x13+0x9=0x139;所以實際上是0x139產生的波特率：115015.97（誤差率為0.15%）；

===》理論最大波特率：36000000/（16*1.0）=2.25M（USARTDIV最小為1.0）

繼續往下查，對于SYSCLK_Frequency最高72M，運行應該沒有問題，但是目前有問題；順藤摸瓜，查看各個時鐘控制器，發現時鐘設置路徑：HSE--》PREDIV2--》PLL2--》PREDIV1--》PLL--》SYSCLK;

發現其中有問題：HSE（25M），PREDIV2（源代碼設置是2分頻），PLL2（8倍頻），PREDIV1（9倍頻），SYSCLK是算不出72M的，這時72M的算法其實已經超過72M，所以給USART2時，波特率計算時會出現問題；將PREDIV2（改為5分頻就對了）；

這就是為什么調用BSP_Init（）或者SystemInit會出問題，他們都調用SetSysClock（），再調用SetSysClockTo72（）【宏定義72M】，同時將系統時鐘改為36M時不會出問題，因為此時調用的不是出問題的SetSysClockTo72（），而在之前用的是出錯的SetSysClockTo72（）卻沒有發現問題，是因為系統時鐘雖沒有在預設值，但是系統還足以正常工作，但是一旦添加串口，波特率設置就會有很大的偏差，數據傳輸就出錯。

1：參考代碼其實里面是有很多問題的

2：我們應該盡可能的多閱讀參考代碼，利用其中的資源，避免重復造輪子。

2：用串口終端軟件顯示字符串，連續發送幾個字符串時，“xxxx/n”，包含了換行轉義字符，但是就是不會換行？

通過調試，發現在存儲空間，轉義字符‘/n’是正確的0x0a，

USART_SendString（USART2，Menu［0］）;

USART_SendString（USART2，Menu［1］）;

USART_SendString（USART2，Menu［2］）;

USART_SendString（USART2，Menu［3］）;

但是不連續發送就不會出現這種現象，或者一句句調試打印也不會出現不換行的現象，斷定是連續發送的時間間隔太短，軟件還沒來得及換行，就又重新顯示新數據，那么就在USART_SendString的尾部加了延時，就解決問題了。

來源：http://www.51hei.com/stm32/4117.html

審核編輯：何安