最近需要在板子上加上一塊WatchDog，以確保在系統(tǒng)出錯時自動重啟，所以看了一些在嵌入式系統(tǒng)中使用看門狗的資料，總結(jié)如下：

一、看門狗原理

在產(chǎn)品化的嵌入式系統(tǒng)中，為了使系統(tǒng)在異常情況下能自動復位，一般都需要引入看門狗。

看門狗其實就是一個可以在一定時間內(nèi)被復位的計數(shù)器。當看門狗啟動后，計數(shù)器開始自動計數(shù)，經(jīng)過一定時間，如果沒有被復位，計數(shù)器溢出就會對CPU產(chǎn)生一個復位信號使系統(tǒng)重啟(俗稱“被狗咬”)。系統(tǒng)正常運行時，需要在看門狗允許的時間間隔內(nèi)對看門狗計數(shù)器清零(俗稱“喂狗”)，不讓復位信號產(chǎn)生。如果系統(tǒng)不出問題，程序保證按時“喂狗”，一旦程序跑飛，沒有“喂狗”，系統(tǒng)“被咬”復位。

這就好比你的身邊有一只時刻饑餓的狗，你不按時給它肉吃，它就會吃你的肉，你被吃了......掛了，投胎轉(zhuǎn)世，徹底重新做人了。不幸的是來世你還得喂狗.

二、看門狗的種類

在現(xiàn)在的嵌入式系統(tǒng)中主要可以分為兩種類型的看門狗：

1、CPU內(nèi)部自帶的看門狗：此類看門狗一般是將一個芯片中的定時器來作為看門狗，通過程序的初始化，寫入初值，設定溢出時間，并啟動定時器。程序按時對定時器賦初值(或復位)，以免被咬。這種看門狗是可以被禁用的(只要停止這個定時器即可)，好比對那只要咬你的狗來個“葵花點穴手”。大部分CPU都內(nèi)置看門狗，硬件原理可參考各芯片數(shù)據(jù)手冊。

優(yōu)點：可以通過程序改變溢出時間;可以隨時禁用

缺點：需要初始化;如果程序在初始化、啟動完成前跑飛或在禁用后跑飛，看門狗就無法復位系統(tǒng)，這樣看門狗的作用就沒有了，系統(tǒng)恢復能力降低。

2、獨立的看門狗芯片：這種看門狗主要有一個用于喂狗的引腳(一般與CPU的GPIO相連)和一個復位引腳(與系統(tǒng)的RESET引腳相連)，如果沒有在一定時間內(nèi)改變喂狗腳的電平，復位引腳就會改變狀態(tài)復位CPU。此類看門狗一上電就開始工作，無法禁用。現(xiàn)在常用的芯片有：CAT705/CAT706、IMP706等等，溢出時間在1.6秒左右。 硬件原理可以參考各芯片數(shù)據(jù)手冊和《基于Linux的嵌入式系統(tǒng)全程喂狗策略》。

優(yōu)點：無須配置，上電即用。無法禁用，系統(tǒng)必須按時喂狗，系統(tǒng)恢復能力高。

缺點：無法靈活配置溢出時間，無法禁用，靈活性降低。

當然還有所謂的軟件看門狗，這其實是也是一種監(jiān)控軟件。

一些重要的程序，必須讓它一直跑著;而且還要時時關心它的狀態(tài)——不能讓它出現(xiàn)死鎖現(xiàn)象。(當然，如果一個主程序會出現(xiàn)死鎖，肯定是設計或者編程上的失誤。首要做的事是Debug。)但如果時間緊迫可以用軟件看門狗，暫時應急。

這種監(jiān)控軟件運行不出現(xiàn)界面窗口，具有一定的隱蔽性;它定時判斷目標進程是否運行在當前系統(tǒng)中，如果沒有則啟動目標進程;判斷目標進程是否“無響應”，如果是則終止目標進程;如果目標進程“無響應”的次數(shù)超過一定的數(shù)量，則重啟整個系統(tǒng)。它的目的也是復位，但是它主要市復位進程，實在不行才復位CPU。

這種軟件屬于監(jiān)控軟件，不在本文的敘述范圍之內(nèi)。

三、看門狗的選擇

在一般的民用產(chǎn)品，對系統(tǒng)的穩(wěn)定性沒有太高要求的場合，可以使用內(nèi)置看門狗，可以簡化軟件開發(fā)和硬件成本。

在工控產(chǎn)品和對系統(tǒng)的穩(wěn)定性有較高要求的關鍵場合，基本都選用硬件獨立看門狗，確保系統(tǒng)在面對嚴重錯誤時的恢復能力。增加了硬件成本，稍微加大了軟件的開發(fā)難度(必須確保在正常情況下的不斷喂狗)。

四、在bootloader下的使用

如果是CPU內(nèi)置的看門狗，一般在這階段可以禁用，所有沒什么特殊的操作。

但是如果是獨立的看門狗芯片就必須喂了。或者為了保險，你在bootloader中就啟動了看門狗，也得喂了。

bootloader有很多，基本原理都是一樣的，喂狗的過程也基本一樣，在這里以uboot為例講解如何喂狗。

u-boot的運行分為以下幾個階段：

最早的簡單初始化，代碼重定位的自拷貝階段

系統(tǒng)詳細初始化階段

控制臺階段(如果使用了自動啟動，則跳過)

OS內(nèi)核拷貝(可能帶有解壓過程)，跳入操作系統(tǒng)

五、在Linux下使用

在bootloader加載了內(nèi)核之后，系統(tǒng)就開始由Linux內(nèi)核接管。而喂狗的工作自然也開始由內(nèi)核來承擔。在bootloader將控制權給內(nèi)核之后，時間上可以分為以下幾個部分：

內(nèi)核自解壓階段(壓縮內(nèi)核才有：zImage或bzImage)

內(nèi)核啟動到看門狗驅(qū)動加載之前

看門狗驅(qū)動加載后到根文件系統(tǒng)啟動前

根文件系統(tǒng)啟動后到看門狗守護進程啟動前

看門狗守護進程啟動后

對于使用CPU內(nèi)置的看門狗，在1～4階段，看門狗一般都沒有啟動，無需喂狗。只有在看門狗守護進程啟動后，由守護進程打開看門狗，并根據(jù)配置文件監(jiān)控其他進程的狀態(tài)來開始喂狗。如果被監(jiān)控進程出現(xiàn)不可修復的問題，守護進程停止喂狗，CPU復位。

對于獨立的看門狗芯片，系統(tǒng)一上電就必須不斷喂狗，接過bootloader的接力棒繼續(xù)喂狗。

首先在第1階段，內(nèi)核的自解壓一般時間較長，必須在自解壓的循環(huán)過程中加入喂狗代碼(可能還要是匯編形式的)。一旦在這過程中跑飛，就不會喂狗，CPU復位。

在第2階段，這段時間一般不會很長，可以不用喂狗。但是這也和你的內(nèi)核有關，如果在這個階段正好有比較耗時的模塊啟動的話，你可以在這個模塊的初始化函數(shù)或者比較耗時的循環(huán)和等待中添加喂狗代碼。具體在哪些模塊中加，要嘗試啟動幾次就知道了，靠實驗和經(jīng)驗。

在看門狗驅(qū)動加載時，一般會在模塊初始化代碼中喂一次狗。

在第3階段，和第2階段類似，如果在這個階段正好有比較耗時的模塊啟動的話，你可以在這個模塊的初始化函數(shù)或者比較耗時的循環(huán)和等待中添加喂狗代碼。但是在根文集系統(tǒng)掛載時，根據(jù)文件系統(tǒng)的性質(zhì)和大小，可能需要在文件系統(tǒng)代碼中添加喂狗指令。

第4階段是一個比較耗時的階段，一般會在系統(tǒng)啟動腳本中添加一些簡單的喂狗的shell命令，例如：“echo V > /dev/watchdog”，加的位置根據(jù)系統(tǒng)的啟動過程而異。

在第5階段，一切都由看門狗守護進程來實現(xiàn)喂狗了。