看門狗安裝包有問題（看門狗在程序中運用）

2023-11-06 07:41:02

看門狗安裝包有問題?看門狗原理：在看門狗使能以後，需要在一定時間內對它進行餵狗，（一般在2S以內）如果沒有及時餵狗，則系統會被復位，系統重新從main處開始運行，今天小編就來說說關於看門狗安裝包有問題?下面更多詳細答案一起來看看吧!

看門狗安裝包有問題

看門狗原理：在看門狗使能以後，需要在一定時間內對它進行餵狗，（一般在2S以內）如果沒有及時餵狗，則系統會被復位，系統重新從main處開始運行。

程序跑飛：當系統受到外部幹擾導致總線錯誤或者數組溢出等錯誤時，會使CPU core的PC寄存器指向一個不可預知的位置。這裡有兩層意思：一是程序一直跑向一個不可預知的地方；二是：程序死在一個循環中。

在抗幹擾實驗中，我們經常會看到這樣的現象，整個系統死機了，但是系統並不復位，即看門狗沒有復位系統。為什麼會出現這樣的現象呢？可能原因之一就是程序死在了一個死循環中，並且在此死循環中執行了餵狗操作，從而導致系統無法復位。所以餵狗操作不能在可能出現死循環中執行，也不能在中斷程序中執行。

現在的CPU體系結構都是基於中斷的，如復位中斷發生時，PC會指向RESET向量處；如定時器中斷發生時，PC會指向定時中斷向量處。在彙編代碼中，RESET中斷地址和定時器中斷地址存放的會是JMP指令，跳向各自的中斷向量函數。所以，main和各個中斷函數是平等的，從宏觀上講，main函數和各中斷函數是並行執行的，只是因為一上電就執行RESET指令，所以main先運行，而其它的中斷函數運行的條件並不是總是滿足的，即使中斷函數被觸發執行，也並會像main一樣，會執行while(true){}，所以我們經常看到的是大部分系統任務都在main中運行，而其它中斷任務處於一個從屬的位置。理解了這樣的前提條件，若餵狗操作在一個1S為周期的定時中斷中執行，即使系統跑飛（我們所說的跑飛大部分是指main中的任務沒有執行），但定時中斷發生時，PC自動裝載定時中斷地址的指令，執行定時中斷函數，執行餵狗操作。定時中斷執行完畢後，執行退棧操作，PC又指向了不可預知的位置，主程序仍沒有執行（如果要main重新開始執行，必須發生RESET），當定時中斷再次發生時，又會在中斷中執行餵狗，如此循環，從而導致系統不會復位。而實質上程序已經跑飛。

在程序中，我們經常會看到這樣的代碼:

While(flag){ if 某硬體條件{ flag = 0; }}

如果硬體損壞或在幹擾下硬體暫時失效，則flag不會被置0，則程序就會死在此循環中，此時就會導致整個系統復位。若在這段代碼中有餵狗操作，即使主程序跑飛，系統也不會復位。如何解決此累問題：一，在檢測硬體條件一定次數之後，如果條件還不成立，則將flag = 0；二，置定時器標誌，在檢測硬體一定時間之後，不管條件是否成立，仍將flag = 0。

那麼餵狗操作應該在什麼地方執行更合理，更能保證程序的健狀性？

void main{ InitSys; while(true){ TASK1; TASK2; ... FeedWatchDog; //執行餵狗操作 }}

整個系統中，此有隻一處有餵狗操作，即如果主任務沒有被執行，則系統一定會復位。

如果TASK1，TASK2。。。。。。TASKn，運行時間加起來大於看門狗復位時間，可以在兩個任務之間插入餵狗操作。