單片機的干擾分析及MCU的改進
加入技術交流群
從表1可見，一個bit的變化完全改變了指令的意義，程序流或數據產生不可預測的變化。例如，表中的跳轉部分（bit 0, 2或5發生變化）可能不轉入死循環，不引起Watchdog動作，也有可能跳到非正常指令處，直至死循環。表中非跳轉指令則有可能改變累加器(bit 0, 1, 3, 4，6或7發生變化)，數據RAM(bit 1,3, 6或7發生變化)或狀態寄存器(bit 0, 1, 3, 4,6或7發生變化)。如果錯誤發生在指令的第2或第3字節，數據的源或目的地址就錯了。因此，即使Watchdog沒動作，也不表示程序運行正常。對8051其他指令作分析可得到類似的結果。由此可見，Watchdog至多保證系統不死機，卻有可能掩蓋了數據的錯誤。本文引用地址：http://www.104case.com/article/171101.htm
F0設計中，在關鍵點大量采用了“MOV dir1,tmp”，“MOV tmp, dir2”的形式將數據從dir1送到dir2，而不采用“MOV A,@R1”類指令，以減小對原始數據破壞的可能性，從而為程序復執創造條件。例如在備份數據Treh到Tbkh時，先將Treh送tmp1，然后將數據由tmp1送到備份Tbkh，再校驗Tbkh與Treh是否一樣。若不一樣，就重作備份。采用的部分程序如下：
MOVtmp1, Tbkh85 53 19
MOVA, tmp1E5 19
XRLA, Treh65 4C
JNZtbkp70 F1
其中“MOV A, tmp1”仍有破壞tmp1的可能性，但tmp1是Treh的拷貝，壞了可重做；“XRL A, Treh”有可能破壞Treh，但已無法作其他選擇。
在硬件抗干擾方面，有許多專用的電源監控芯片，如TL7705等，但是它們只適合在較慢的電源擾動下使用。對于直流電源的跌落干擾，MCU根本來不及作現場的保護工作，所以它不是解決快速干擾問題的辦法。
在F0中使用的辦法也不盡完善，一般單片機線路中還有很多外圍線路，例如F0中的光耦，3個光耦同時導通時要消耗約50 mA的電流，它們形成的動態電阻很小，發生電源跌落時，并聯于MCU的解耦電容對此電阻放電，無法保證MCU正常工作的額定電壓。如在MCU電源中串接高頻二極管，就會引起額外的電源消耗，在低功耗的應用中也會形成新的缺點。有些功能強大的MCU本身功耗就大，容許的電源變化范圍小，能否依靠解耦電容對抗電源跌落還需要檢驗。綜上所述，軟件解決辦法不徹底，硬件解決辦法也有很多缺點與限制。
3 MCU要增加的功能
由于干擾而使指令出錯的問題不是Watchdog能解決的，特別是造成源數據錯時，程序復執也不能糾正錯誤的結果。程序設計者要在現成的指令體系中找到對源數據危害性概率最小的指令不容易。即使找到，也不能保證指令在有多bit跳變時源數據不錯。另外，有些指令錯誤也可能破壞其他處的數據。利用破壞數據概率最小的指令設計程序也不是好辦法，它既耗ROM空間，又費運行時間。
增大指令的Hamming距離可以改善這一情況。例如，給指令增加一到數位校驗位，一旦指令通不過校驗，就不執行，并重新取指。這樣，問題就有可能在產生后果前解決。就目前MCU的設計與生產水平而言，在技術與成本上這種增加不會有很大困難。雖然這一辦法在添加的校驗位有限時仍會有一定出錯概率，但這種概率可以小到能接受的程度。
為了更為可靠，作校驗的線路可有某種冗余。連續重取指可能反映有其他故障，應通過某種方式通知應用層。為了不打擾程序設計者，這些指令的添加位應該在寫入ROM時自動生成，這樣就不會產生與現有產品的兼容性問題。
在早期的MCU應用中，Watchdog是外置的，后來都集成到MCU里面去了。如果實現上述功能，MCU的抗干擾能力會更強，Watchdog可能就不需要了。軟件的可靠性分析就可以將程序走飛和數據的完整性問題分割出來加以處理，軟件部分更專注于邏輯分析，意義深遠。
評論