前不久，幾乎舉國上下在同一時間段內整齊劃一地被感染了新冠。

很多人感染后都不同程度地出現味覺、嗅覺失靈的情形。本人也有相同經歷。這幾天，味覺恢復，嗅覺也在慢慢恢復中。既能聞到誘人的煎餅香，也能聞到清新的花香了。

今天在此分享兩個STM32應用中的實戰案例，權作提醒，以免重蹈覆轍。

案例1:

系統聯機工作時，Flash編程偶發性失敗

有人使用STM32F4系列芯片做開發，代碼里涉及到FLASH編程。他發現FLASH編程過程中時不時地出現編程錯誤，即提示HAL_FLASH_ERROR_PGP錯誤。

他的產品系統有用到CAN通信。當他不將芯片做系統聯機工作時不會發生該錯誤，只有在做整體聯機測試時才可能發生編程異常。

起初，客戶使用4字節編程模式，平常單獨就flash編程功能測試也正常，整體聯機運行時才可能出問題。后來，無意中嘗試將FLASH單次編程寬度調整為1個字節后則異常消失。

那是為什么呢？

其實，在做FLASH編程時，選擇不同的編程寬度所需的芯片供電電壓是不一樣的。上面截圖來自STM32F4系列參考手冊。從圖中不難看出，選擇的編程寬度越寬，芯片所需供電電壓越高。

若不運行其它功能，只是單獨就芯片做flash編程，功耗需求相對較小、電源波動也小。當聯機工作時，系統功耗、串擾都有所增大，電源波動也可能加劇，這時很可能出現電源難以保證支持4字節編程方式的穩定需求。由于單字節編程模式所需電源電壓相對較低，在系統聯機工作時，相同的電源條件下，即使電源有所波動，但完全可能依舊能提供滿足單字節編程的穩定電壓需求，因而不會出現因供電問題導致的編程異常。

案例 2:

芯片工作時偶發性出現死機現象

有人在做STM32芯片做產品開發，會偶發性地出現芯片進入死機狀態的現象。

代碼里有做FLASH編程操作，有UART的收發動作及相關中斷，另外還開啟了某定時器更新中斷。經過測試發現，如果關閉定時器中斷，FLASH編程、UART收發動作保持的情況下，則不會出現死機的現象。可是定時器中斷怎么會導致芯片死機呢？感覺沒有找到根本原因。后來，進一步跟蹤調試發現，芯片出現死機，實際上是程序不停地進入UART接收中斷。

用戶代碼里的確使能了UART收發中斷，但在中斷代碼里程序實實在在有對接收非空標志【RXNE】做清零處理，不應該沒完沒了地進接收中斷啊！經進一步確認，發生死機現象時總是對應著UART接收溢出事件【ORE】。哦，如果這樣，當UART接收發生溢出時的確也會產生接收非空中斷。下圖為STM32USART的各個中斷請求事件及中斷使能控制位。從下圖可以看出，當使能RXNEIE時，RXNE和ORE事件都可產生接收中斷。

用戶雖然在UART接收中斷里有對RXNE標志清零，但當發生溢出事件而進入中斷時，他并沒有對ORE標志做檢測及相應的清零操作。

實際上，用戶根本就沒有意識到發生ORE事件時也可以產生接收中斷，在其代碼里根本沒有對ORE標志進行檢測，更沒有對ORE標志做清零，導致UART接收中斷沒完沒了的進入，感覺芯片猶如死機一般。

為什么關閉定時器中斷能防止死機現象發生呢？ 我們知道，UART接收產生溢出是因為數據接收到后不能及時取走才產生的，而定時器中斷的存在,因為中斷競爭的原因導致了UART接收中斷的及時性受到影響，進而容易發生溢出。如果關閉定時器中斷或或將UART接收中斷的優先級配置成可以搶占定時器中斷就可以避免UART接收不及時的問題，也就不會發生溢出。這樣的話，即使用戶的UART接收中斷里沒有對ORE事件的處理也無所謂。

當然，我們做UART的中斷接收時，中斷代碼里最好加上對ORE事件的檢測處理,當發生溢出事件時，及時對ORE事件標志清零。否則,萬一發生溢出，就可能因ORE事件而發生沒完沒了進中斷的問題，進而導致功能異常。

具體到本案例，再順便提醒一點，除非片內FLASH采用雙BANK結構，FLASH編程也是會影響中斷響應的。即該操作也可能讓UART的接收中斷的響應因臨時堵塞而發生接收溢出。

好，今天的分享到此打住。也愿這里的分享能給有需要的人帶來一些幫助。

目前尚是冬季，大家注意防寒保暖并保證休息,以利新冠康復。如有咳嗽，除了使用適當藥劑外，盡量避免說話，尤其是高聲說話。

待到山花爛漫、綠柳如煙時，魑魅魍魎盡遁去。九州華夏重抖擻，東方旭日耀寰宇。~~~~~~一起加油！~~~~~

審核編輯：湯梓紅