STM32 串口USART調試Error

關于stm32串口接收大量數(shù)據導致死機，即使加了看門狗也死機的情況，論壇上已有熱心網友分享樂寶貴經驗，至于效果，應該是有的。未能免俗，也來分享，狗尾續(xù)貂了。

原文網站：http://bbs.21ic.com/icview-160999-1-1.html感謝這位網友分析問題。

首先，造成死機的原因多種多樣，本人做的實驗室用串口接收飛控數(shù)據，波特率57600。大量數(shù)據導致串口中斷頻繁，理想情況下，設置好中斷優(yōu)先級應該是可以有條不紊的處理數(shù)據。我遇到的情況是

1、設置看門狗，只用定時器喂狗，main函數(shù)沒有做任何處理，串口開了一段時間，main函數(shù)掛了，可是喂狗一直在跑，程序不復位，那也就說某些外設在不斷的跑，或者跑飛，main函數(shù)回不來；

2、第一種情況不會使程序復位，于是在main函數(shù)里邊設置定時器的標志位，main函數(shù)處理之后，定時器才能喂狗，這種情況程序跑飛，喂狗便不成功，自動復位。

3、兩種情況都未能解決問題，于是只好模塊測試，最后分析到時串口中斷頻繁，卡死在串口中斷里面

找了網上資源，了解到的是串口數(shù)據頻繁，會造成一個中斷溢出現(xiàn)象，也就是說本次數(shù)據沒有處理完成，下一次數(shù)據又進來了，導致所謂的溢出錯誤

那么問題來了，按照常規(guī)思維，在初始化串口時，原本沒有打開所謂的溢出錯誤中斷，也就是ORE中斷，為何會產生這個中斷呢？看到數(shù)據手冊，坑爹的邏輯來了，

手冊寫的是你只要接收中斷打開，即RXNEIE設置為1，那么ORE中斷也自動打開了。

這不符合正常邏輯，于是乎在串口2中斷里面應該做相應的處理，防止產生意想不到的中斷，因此，中斷函數(shù)應該寫的嚴謹一些

void USART2_IRQHandler(void)

{

uint8_t ch;

if(USART_GetFlagStatus(USART2, USART_FLAG_PE) != RESET)

{

USART_ReceiveData(USART2);

USART_ClearFlag(USART2, USART_FLAG_PE);

}

if (USART_GetFlagStatus(USART2, USART_FLAG_ORE) != RESET)

{

USART_ReceiveData(USART2);

USART_ClearFlag(USART2, USART_FLAG_ORE);

}

if (USART_GetFlagStatus(USART2, USART_FLAG_FE) != RESET)

{

USART_ReceiveData(USART2);

USART_ClearFlag(USART2, USART_FLAG_FE);

}

if(USART_GetITStatus(USART2, USART_IT_RXNE) != RESET)

{

//USART_ClearITPendingBit(USART2,USART_IT_RXNE); //清除中斷標志

ch = USART_ReceiveData(USART2);

USART_ClearITPendingBit(USART2, USART_IT_RXNE);

}

}

因此，在中斷里面，即使產生了所謂的溢出中斷，也不會導致程序死在串口中斷。

另一個是本人試驗中犯的低級錯誤，串口接收使用的是循環(huán)數(shù)組接收，數(shù)組序號不斷往上加，而在main函數(shù)中循環(huán)獲取數(shù)據，那么問題來了。

箭頭里面的==號應該寫為>=這樣防止變量++之后溢出而不歸零，于是把這問題改了

在此之上，把USART2_BUFFER_LEN調大，stm32內存大著呢，隨便用，竟然神一般的好了，腰不疼，腿不酸，程序跑了一個多小時，還在！

以此分享，共同進步！