問題描述
控制系統使用的是STM32F4+UCOSII 搶佔型內核，最近一段時間出現了程序跑一段時間之後操作系統直接死掉的問題，表現爲：操作系統中設有優先級很低的呼吸燈任務，只要操作系統在正常工作，呼吸燈就會不停的跳動，但是當出現問題時，呼吸燈停止跳動，控制底盤運動的任務也死掉，底盤處於失控狀態，LCD所在的任務也死掉，不再進行刷新，推測爲所有的操作系統的任務均死掉，不能正常工作，但是中斷仍然可以響應，寫在定時器中斷中的急停操作是可以執行的。
問題分析
- 懷疑是進入了一些錯誤中斷
- 懷疑是指針或者堆棧出了問題
- 懷疑最高優先級的任務中存在死循環
- 懷疑操作系統中存在一些bug
- 懷疑是中斷引起的程序一直在中斷中，不能進入正常任務
解決方案 對錯誤中斷進行排查分析，程序中開啓的錯誤中斷響應只有HardFault，在進入HardFault的中斷服務函數後會進行相應的處理
`/* *- @brief This function handles Hard Fault exception.
- @param None
- @retval None
*/
void HardFault_Handler(void)
{
/* Go to infinite loop when Hard Fault exception occurs */
while (1)
{
BEEP_TOGGLE;
Delay_ms(500);
}
}`
因此，從表現上看基本可以排除進入Hard Fault的可能，除此之外，Hard Fault的中斷優先級爲 -1，如果程序是死在HardFault中，那麼其他的中斷響應應該也是無法響應的，這與問題的表現，中斷仍然可以響應矛盾，因此可以斷定，不是進入了HardFault和其他的一些問題中斷。
關於指針和堆棧的問題，一般有問題會直接進Hard Fault，而此時基本已經排除了Hard Fault的問題，除此之外也嘗試擴大了硬件和操作系統的堆棧，問題沒有解決，確定不是這裏有問題。
關於操作系統的Bug在網上查了不少，早期的操作系統確實存在問題但是系統中使用的2.92版本應該是不存在此類Bug的。
總結
上述對問題的解釋其實有點牽強，因爲大多數時候發送和接收都是這樣進行處理的，但是都沒有出現問題，而且DMA的使用也使用了很長時間也沒有出現過問題，並且就算出問題也是隨機的，並不是每次都出問題，所以懷疑出現問題應該是跟各個中斷之間的優先級、響應時間、以及具體的時序有一些複雜的關係，具體是什麼關係就很難尋找了，推薦的做法就是防範於未然，將不用的中斷統統關閉，這樣總是沒有壞處的。