關于單片機軟件狗的討論

摘要:文章指出了一種廣泛流傳的誤解:在mcs-51系列單片機中,只要用指令使程序從起始地址開始執行,就可以復位單片機,擺脫干擾。通過一個簡單的實驗,揭示了軟件復位的可靠方法。
有的單片機(如8098)有專門的復位指令,某些增強型mcs-51系統單片機雖然沒有復位指令,但片內集成了watchdog電路,故抗干擾也不成問題。而普及型mcs-51系列單片機(如8031和8032)既然無復位指令,又不帶硬件watchdos,如果沒有外接硬件watchdog電路,就必須采用軟件抗干擾技術。常用的軟件抗干擾技術有:軟件陷阱、指令冗余、軟件watchdog等,它們的作用是在系統受干擾時能及時發現,再用軟件的方法使系統復位。所謂軟件復位就是用一系列指令來模仿復位操作,這就是mcs-51系列單片機所特有的軟件復位技術。
現用一簡單的實驗說明,實驗電路如附圖所示。接于仿真插座p1.0的發光二極管led0用來表示主程序的工作情況,接于p1。1的發光二極管led1用于表示低級中斷子程序的工作情況,接于p1。2的發光二極管led2用來表示高級中斷子程序的工作情況,接于p3。2口的按鈕用來設立干擾標志,程序檢測到干擾標志后故意進入死循環或掉進陷井,模仿受干擾的情況,從而檢驗各種復位方法的實際效果。寮驗初始化程序如下:
org 0000h
stat: ljmp main ;復位入口地址
ljmp px0 ;按鈕中斷向量(低級中斷)
org 000bh
ljmp pt0 ;t0中斷向量(低級中斷)
org 001bh
ljmp pt1 ;t1中斷向量(高級中斷)
org 0030h
main:
clr ea
mov sp,#7
mov p1,#0ffh
mov p3,#0ffh
mov tmod,#11h
clr 00h ;干擾標志初始化
setb et0
setb et1
setb ex0
setb pt1
setb tr0
setb tr1
setb ea
loop: cpl p1.0 ;主程序發光二極管led閃爍
mov r6,#80h
mov r7,#0
tt1:
djnz r7,tt1
djnz r6,tt1
sjmp loop
px0:
setb 00h ;設立干擾標志,模擬發生干擾
pt0: cpl p1.1 ;低級中斷程序發光二極管led1閃爍
reti
pt1: cpl p1.2 ;高級中斷程序發光二極管led2閃爍
reti
end
實驗步驟如下:
1． 按上述程序啟動執行,三個發光二極管都應閃爍(否則應先排除故障),表示主程序和各中斷子程序正常。因模擬干擾標志未加檢測,故不受按鈕影響。
2． 修改主程序如下,按下按鈕后主程序即掉入死循環中。
loop: cpl p1.0
mov r6,#80h
mov r7,#0h
tt1: djnz r7,tt1
djnz r6,tt1
jnb 00h,loop ;受干擾否？
stop: ljmp stop ;掉入死循環。
這時可以看到,主程序停止工作(led0停止閃爍),而兩個中斷子程序繼續運行(led1和led2繼續閃爍)。
3． 將定時器t1妝作軟件watchdog,將30h單元用作軟件watchdog計數器。主程序中加入一條復位軟件watchdog的指令。
loop: cpl p1.0
mov 30h,#0 ;復位軟件watchdog計數器
loop: cpl p1.0
mov r6,#80h
mov r7,#0h
tt1: djnz r7,tt1
djnz r6,tt1
jnb 00h,loop ;受干擾否？
stop: ljmp stop ;掉入死循環。
t1中斷子程序修改如下:
pt1: cpl p1.2 ;高級中斷程序發光二極管閃爍
inc 30h
mov a,30h
add a,#0fdh
jc err ;達到3次否？
reti
err: ljmp stat ;軟件watchdog動作
當按下按鈕前,程序正常運行(三個led全閃)。按下按鈕后,主程序能迅速恢復工作,但兩個中斷子程序被封鎖,不再工作。過程如下:主程序檢測到干擾后進入死循環,不能執行復位30h單元的操作,t1中斷使30h不斷增值,計數到3時,軟件watchdog執行動作,執行一條ljmp指令,使程序從頭執行。main過程中清除了干擾標志(表示干擾已經過去),使主程序迅速恢復工作。按理說main過程中也重新設定了各個中斷,并開放了它們,為什么中斷不能恢復工作呢？這是因為中斷激活標志的復位工作被遺忘了,因為它沒有明確的位地址可供編程,直接轉向0000h地址并不能完成真正的復位。軟件復位是使用軟件陷井和軟件watchdog后必須進行的工作,這時程序出錯完全有可能發生中斷子程序中,中斷激活標志已置位,它將阻止同級中斷響應。由于軟件watchdog是高級中斷,它將阻止所有中斷響應。由此可見,清除中斷激活標志的得要性,很多文獻的作者回為沒有認識到這一點進入誤區。
4． 在所有指令中,只有reti指令能清除中斷激活標志。出錯處理程序err主要是完成這一功能,其它的善后工作交由復位后的系統去完成。為此,我們重新設計t1中斷子程序如下所示:
pt1: cpl p1.2 ;高級中斷程序發光二極管閃爍
inc 30h ;軟件watchdog計數器增值
mov a,30h
add a,#0fd
jc err ;達到3次否？
reti
err: clr ea ;關中斷
clr a ;準備復位地址(0000h)
push acc
push acc
reti ;清除中斷激活標志并復位
這段程序先關中斷,以便后續處理能順利進行,然后用reti指令替代ljmp指令,從而既清除了中斷激活標志又完成了轉向0000h的任務。按這樣改好后程序再運行,結果仍不理想:按下按鈕后,有時只有主程序和高級中斷子程序能迅速恢復正常,而低級中斷仍有被關閉的可能。如果按如下方法把干擾轉移到低級中斷中,則按下按鈕后低級中斷必然被關閉:
loop: cpl p1.0
mov r6,#80h
mov r7,#0h
tt1: djnz r7,tt1
djnz r6,tt1
sjmp loop
pt0: cpl p1.1
jb 00h,stop
reti
stop: ljmp stop ;掉入死循環。
仔細分析后可能得出結論:當軟件watchdog是嵌套在低級中斷中起作用時,復位后只清除了高級中斷激活標志,低級中斷標志仍然被置位,從而使低級中斷一直被關閉。
5． 修改出錯處理如下:
err: clr ea ;正確的軟件復位入口
mov 66h,#0aah ;重建上電標志
mov 67h,#55h
mov dptr,#err1 ;準備第一次返回地址
push dpl
push dph
reti ;清除高級中斷激活標志
err1: clr a
push acc
push acc
reti ;清除低級中斷激活標志
這時,必須執行兩次reti,才能到達0000h,以保證清除全部中斷激活標志,達到和硬件復位相同的效果。同樣,軟件陷井也必須由下列三條指令
nop
nop
ljmp stat
改成:
nop
nop
ljmp err
才能達到目的。
當主程序受到干擾被軟件陷阱捕獲時,中斷標志并未置位,執行err過程中,reti指令等效于ret指令,同樣可以達到軟件復位的目的。有興趣的讀者可以將軟件陷阱代替死循環,分別用ljmp stat和ljmp err1來替代ljmp err,再將干擾檢測分別設在低級中斷和主程序中,實驗結果必然證明同:只有ljmp err才能萬無一失地實現軟件復位,使系統擺脫干擾同,恢復正常。在mcs-51單片機的軟件復位過程中,必須連續執行兩次中斷返回指令reti才能確保系統恢復正常。

張明峰 (1899-12-30)
由于51單片機指令結構是多字節的,在受到干擾后pc有可能被篡改,既然pc的值被篡改了,你就無法預先知道篡改后程序飛到哪里。如果是它落在一條合法的指令上,問題還不大;如果它落在一條指令的操作數上(多字節指令,一個字節操作碼,后跟一個或多個字節的操作數),單片機就會把該操作數作為操作碼來譯碼執行,這時情況就嚴重了 - 后面有多少指令是不可預測的？天知道!它們做了哪些具體的操作？也是天知道!那么,有一種可能性必然存在:程序飛了后把相關的中斷給關了,這時,你上面的方法還有效嗎？

我常對客戶的工程師這樣說:你的系統如果需要用到看門狗,千萬不要用軟件看門狗;用了硬件看門狗,千萬不要在中斷里面清看門狗。有時軟件死循環了,但中斷還能進入,如果靠中斷清看門狗,就永遠不能退出死循環。

style (1899-12-30)
對原文的補充:div/mul指令可能會異常,但極罕見.

fibro (1899-12-30)
軟件看門狗好像只是在理論,教學中使用,真正應用就連用硬件看門狗都不放心,還敢用軟件的???!!!

zxcasd (1899-12-30)
請問各位:難道軟狗真的連一點作用都沒有嗎?

liuq (1899-12-30)
單純地談可靠性的問題,不應該簡單地從有無watchdog方面考慮。更重要的是從影響性能穩定、運行可靠的因素方面,排除干擾源對所設計系統的作用是至關重要的!
有位業界的朋友說:“完成軟硬件的設計,只是一個產品設計的十分之一,更多的是去做系統的可靠性、工藝性、合理性方面的工作”。
我認為能夠滿足一個設計,所有品牌的mcu都是一樣的。當然在選型時,有些小公司的mcu產品是要予以考慮的。
我見過的很多電子產品(工業應用產品,進口產品)并沒有使用watchdog!當然有watchdog要比沒有watchdog的要好,這是事實,但不應該把救命稻草寄托在watchdog之上!首先是要系統能夠抵御外部的影響和干擾!
歡迎討論!

style (1899-12-30)
不同意樓上的看法.
是否安裝軟件狗完全取決于系統需求,在很多應用里,狗叫了意味著系統的徹底失敗,就像火箭發射了以后不可能再回到地面.這些應用才是追求系統的高可靠性.

平凡 (1899-12-30)
to:張工
您的意見不敢茍同。沒有什么場合是需要看門狗的,用看門狗是沒有辦法的辦法,它是只增加系統的可靠性而已,一個系統是否用看門狗,和設計者有很大的關系,而不僅僅是和系統本相關。軟件看門狗可以提高系統的可靠性,硬件看門狗也可以增加系統的可靠性,就同一個設計者來說,可能硬件看門狗設計、使用更方便,而軟件看門狗則需要更高的技巧,設計得不好反而容易出麻煩,所以可能使用軟件看門狗的可靠性不及使用硬件看門狗。但即便如此,軟件看門狗還是可以在一定程度上提高系統的可靠性的(和不用相比)。而對一個高手而言,可能他根本不需要用看門狗就可以把系統的可靠性設計得比用硬件看門狗還可靠。所以我認為研究軟件看門狗的技術也是有價值的,在一些場合是可以應用的。

張明峰 (1899-12-30)
100%同意平凡老師的意見。用肯定比不用強。其實我以前也一直這么用的。如故意寫連續的5/6條nop指令,目的不是為了延時,而只是想讓跳飛了的程序走回正軌。我提上面的問題只是想說明軟件看門狗的局限性而已,只要做過具體產品設計的人,都少會有體會。

抗干擾的問題是一個系統設計的問題而不僅僅是一個芯片如何如何的問題。但現在很多設計人員關注的僅僅在于某顆芯片怎么好或怎么不好。如果覺得芯片好而置其它考慮因素于不顧(最常見如pcb layout),不知是不是誤區？

平凡 (1899-12-30)
不過要是芯片抗干擾性高的話,其他地方能省點事又何樂而不辦呢？不過這樣就是培養不出水平了。要是一個項目一定指定用那個芯片,或者由于成本、供貨等原因,沒法用高抗干擾的芯片,就沒辦法了,所以還是多掌握一點技術的好。

5130840 (1899-12-30)
單片機失控的表現,看來看去,好象有以下表現:
其一,在指令執行中失控,尤其對變指令系統尤為有理,讀了不該讀的數據,譯了不該譯的指令,對這些情況,經典教科書中都有論述。
其二,表現為reti,和ret的跳轉關系,21ic中有多篇可以參考。
問題:
是否存在這樣一種情況:
單片機處于halt狀態,好象正常,又不能正常工作。
如果存在,對這種情況,watchdog是否一定能使單片機回到正常工作的狀況？