文章介紹了嵌入式系統開發過程實際上就是一個調試診斷的過程，而且調試診斷將一直伴隨著一個產品的終身，即使是最成熟的產品也偶爾會出現這樣或那樣的問題，這都需要開發人員去診斷、排查。

嵌入式系統的調試包括硬件調試、軟件調試以及綜合調試。硬件調試一般是指系統剛開發出來時上電前后的檢查，包括：

1)上電前檢查電源和地是否短路，目視檢查是否有虛焊、漏焊;

2)上電后檢查時鐘線上的頻率和波形、幅度是否正常，各電源電壓是否穩定正常，各芯片溫度是否正常，各指示燈是否正常。

軟件調試一般是指保證硬件一切正常的情況下驗證程序執行的時序是否正確，邏輯和結果是否與設計要求相符，能否滿足功能和性能要求等。軟件調試的方法有很多，包括：

1)用指示燈跟蹤調試;

2)用串口打印調試;

3)用簡單的調試器進行匯編代碼級調試;

4)用比較高端的調試器進行源代碼級調試;

5)用仿真器進行硬件仿真。

上述單純的硬件調試或軟件調試都是相對比較簡單的，困難的是綜合調試。下面我先舉一些自己在工作中曾經碰到的疑難問題，然后再從中歸納出一些一般的調試方法和注意事項。

例 1：我們自主設計制作的PPC860(Motorola)網絡引擎平臺的調試已接近尾聲，同一批生產的4塊板子都通過了全部軟件測試，于是又去焊了第二批，可是在第二批板子中有1塊板子的FEC不能正常工作，我們幾個軟件和硬件工程師使用了各種手段，重新看了多遍芯片手冊，還是沒找出原因，于是把板子發回工廠重新焊接BGA，可是回來問題還是照樣存在，沒辦法最后打算將這塊板子當作個樣處理，把板子上的芯片都焊下來。按常理來說這種做法很符合邏輯，因為元器件都是一樣的，板子也是一批的，那就可能是這塊板子的某個地方焊接不好，但又不好查，反復重新焊接可能會把主板焊壞。后來有人從PPC860芯片上用放大鏡都要睜大眼睛才能看清的字符上(據說我國第一代國產高端處理器芯片“寒心”就是某“科學家”將“摩托”同一類型芯片上的這些字母磨掉后刻上“寒心一號”搖身一變造出來的!!!)發現這塊板子的CPU版本號是“D4”，而其他板子的CPU版本號是“D3”，可芯片手冊上并沒有這兩個版本之間的比較說明，從網上找到PPC860的勘誤手冊，發現在PPC860TZP50D4版本中，ECNTRL寄存器增加了一個叫FEC_PIN_MUX的位(bit2)來控制FEC各管腳的復用功能，如果要使用FEC就必須將該位設置為1，所以要在FEC的相關程序中加上ECNTRL |= 0x00000004語句行。

例2：當我調試業余自制的MC68VZ328板子時，電路板硬件檢查沒有問題，用Code warrior通過串口往flash中燒制編譯好的uClinux程序也一切正常，但是重新上電，發現串口沒有任何數據，用萬用表檢查(當時自己沒有示波器等“先進設備”)也沒查出結果，然后每天上下班把這塊板子放在包里，沒事就拿出來瞪大眼睛看看，看著也不免窩火，但有一天卻發現一個標著電阻符號的地方卻焊上了電容，回到家把電阻換上去再上電，串口一下就打印出uClinux的啟動信息，呵，那滋味，比喝了蜂蜜都甜，當然當時也是因為沒有太多經驗，如果這問題放現在，估計一天內肯定解決掉。另外在初次調試自制的S3C4510開發板時，就是不能從串口輸出字符，費了半天時間才發現把串口電平轉換芯片 max3232cse的第6腳上的旦電容極性焊反了。

例3：在調試SB1250嵌入式服務器主板時，由于使用的是DDR1代內存條，數據線和時鐘線上串并聯的去耦電容電阻相當多，第一批焊回來的板子幾乎沒有一塊能夠順利進入CFE(BIOS)菜單界面的，檢查時鐘波形和電源與借用的 DEMO板相比都很好，我把主板上DDR DIM槽周圍的那些去耦電阻電容都全部用烙鐵重新過一遍錫，嘿嘿，還真管用，這種方法屢試不爽，而且在后面調試PCI和HT總線時使用這招也很有用，可能是因為SB1250系統是高頻電路，對焊接要求比較高，稍微有一點漏焊或者虛焊都不行，我是這樣認為的。

從上述幾個例子中我們可以總結歸納以下幾點調試方法和注意事項：

1)加深理解法：加深理解包括加深對硬件和軟件的理解，加深對硬件的理解主要是詳細閱讀相關的芯片數據手冊，而加深對軟件的理解是因為現在開發嵌入式系統并不是所有程序都需要自己編寫，很多都是已經做好的，直接從網上獲取或者采購獲得，但這些軟件不一定是完全針對我們自己的目標板的，所以在使用過程中經常會發現一些問題，特別是底層軟件，而一旦出現問題，開發人員首先必須了解出現問題的代碼。只有建立在對相關硬件和軟件深入理解的基礎上才可能做出更符合實際的判斷，才可能更好地解決問題。

2)比較法：比較的方法有很多，比如將同樣的軟件放在兩個類似但不相同的硬件平臺上運行比較現象;將兩個不同版本的軟件放在同一個硬件平臺上運行比較現象;將相同的軟件放到相同批次但不同的兩個硬件平臺上運行比較現象。對于一些不是很隱蔽的問題通過比較法通常能得到不錯的效果。

3)分解法：當碰到分析起來比較復雜、可能有很多因素的問題時，可以把問題分成解幾個小問題來測試診斷，比如編寫幾個單獨的小測試程序對各種可能因素進行排查測試，根據這些測試結果再進行科學判斷。

4)軟硬件結合法：這種方法是需要一定靈感和悟性的。比如上面的例5，在測試過程中，可以在不破壞硬件的前提下臨時改變一下硬件的狀態(比如該例中將數據線和時鐘線短路)，看問題現象會不會有所變化，如果有，那么多做類似試驗找出變化規律和關鍵因素，然后再進行分析解決。在底層軟件開發中，對于時序要求嚴格的硬件模塊的軟件編程要特別注意，一旦程序的時序出了問題，而這部分軟件已經與其他系統軟件融合到一起，那么這種軟件讓別人去檢查是很難查出問題的。

5)診斷、排故要建立在大量實驗的基礎之上，要多動手，不能光知道臆想，不愿實際操作，還美其名曰“善于思考和分析”。嵌入式系統開發是一門實踐性很強的科學，需要在實踐中總結出事物客觀規律，從而更好地認識和利用它們，讓它們更好地按我們的意圖工作。

6)嵌入式系統開發調試要求開發人員有嚴謹細致的工作態度，決不放過調試過程中發現的任何一點蛛絲馬跡，因為它很可能就是打開潘多拉寶盒的鑰匙。

7)要有實事求是的工作作風，要有敢于懷疑一切的精神和勇氣，我們理當尊重權威和前人的科技成果，但當出現矛盾時我們更應該相信實驗結果，這樣科學才會進步。

8)要勇于挑戰自我，拋開習慣性思維和成見，拓寬思路，多角度分析問題。

9)嵌入式系統開發特別是底層軟件和操作系統內核開發因為需要同時跟軟件和硬件打交道，所以是一件比較艱苦的工作，很有挑戰性。即使我們各方面都做得非常好，考慮得非常細致周全，目標系統仍然可能跟我們開一些小小的玩笑，我們經常會碰到一個非常小的問題困擾我們幾天甚至幾周的時間，這期間我們可能茶飯不思、夜不能寐，因此嵌入式系統底層軟件開發人員不但要有平和的心態，且具備一定的耐心和毅力，還要有勇于克服一切困難的勇氣和信心!只要我們做得足夠好，那么可能解決一個具體疑難的過程帶有一定偶然性，但我們終將排除所有阻礙!

所以說，嵌入式系統調試過程就是一個更加深入了解我們的目標系統以及系統中的每個單元模塊特性的過程，就是一個鍛煉我們的邏輯思維和分析推理能力的過程，就是一個開拓思路、向習慣思維和權威挑戰的過程，就是一個培養嚴謹細致的工作態度和實事求是工作作風的過程，就是一個鍛煉我們耐力和毅力的過程，最終是一個學習進步的過程!

嵌入式系統調試診斷能力的提升是一個長期實踐、積累、提高的過程!