摘自
http://blog.csdn.net/broadview2006/archive/2009/02/25/3935987.aspx------講述了硬件調試/軟件調試/綜合調試. 并通過幾個例子總結歸納了幾點調試方法和注意事項. 不錯!
嵌入式系統開發過程實際上就是一個調試診斷的過程，而且調試診斷將一直伴隨著一個產品的終身，即使是最成熟的產品也偶爾會出現這樣或那樣的問題，這都需要開發人員去診斷、排查。
嵌入式系統的調試包括硬件調試、軟件調試以及綜合調試。硬件調試一般是指系統剛開發出來時上電前后的檢查，包括：
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系統是高頻電路，對焊接要求比較高，稍微有一點漏焊或者虛焊都不行，我是這樣認為的。
例4：在一個使用實時時鐘芯片 SD2000的應用系統中，經常會出現讀出的時間被復位到 “2000年1月1日”的情況，我用自己編寫的測試程序經過多次測試發現，按照SD2000芯片手冊中的時序進行連續讀寫確實會經常出現復位現象，好像是芯片錯把讀寫時序當成了復位操作時序，而且每次必出，所以我感覺到芯片本身應該有Bug，于是告訴同事可能是芯片本身有問題，讓他跟廠家聯系，但因為這個芯片在老產品中用了比較長的時間，所以同事不太認同我的看法，但還是與SD2000廠家取得了聯系，廠家經過兩天專門強化測試后通知我們“SD2000本身確實有Bug，可能因為干擾導致芯片復位到2000年1月1日”。
例5：在用PNX1700（DSP）處理器設計成的音視頻開發平臺上，常會出現CVBS輸出黑白圖像（應該是彩色）或顏色不正常現象，于是先詳細閱讀CVBS輸出芯片AVS3169的手冊，然后用示波器測量3169芯片的時鐘管腳，在測量的過程中經常會出現顏色恢復正常的現象，再做多次測試發現這種現象是由于將場同步VSYNC信號與相鄰的數據線Data7短路造成的，再測試發現將VSYNC與其他數據線（Data[0:6]）任一根短接一下都可以恢復正常，再用視頻時鐘信號CLK與數據線短接一下有時也能恢復正常，但有時也不能恢復，所以懷疑是視頻場同步信號有問題。順著這根線索查了一下AVS3169的VSYNC信號與PNX1700的連接方式，發現在用CVBS輸出時，PNX1700上與AVS3169的VSYNC信號相連的引腳是輸出QVCP_VSYNC信號，檢查VO輸出模式設置沒有問題，再查QVCP的設置，看哪個寄存器能控制QVCP_SYNC信號，發現在QVCP_CONTROL(0x10e020)寄存器中有對HSYNC和VSYNC的控制，用命令在線修改了直接相關的該寄存器中4個位的值，但沒有任何效果，再在整個PNX1700芯片手冊中查找關鍵字VSYNC，發現在398頁有對QVCP VSYNC設置要求的描述：該寄存器的bit1(Master)要求設成1，即從模式，而我們現在是設成0，即主模式，我把該位改成1后屏幕出現黑屏，沒有任何顯示，再把這位恢復到0，竟然出現了顏色，屢試不爽，仔細研究這個寄存器的bit1和bit0分別是控制屏幕時鐘發生器（STG）工作模式（主/ 從）和STG的復位，分析覺得在系統上電后對QVCP初始化之前先把QVCP的STG置成從模式并且復位STG，然后再用原有的初始化程序，這樣應該可以解決視頻信號的時鐘和數據不同步問題，所以在主程序中初始化QVCP之前加入MMIO(0x10e020) = 0x20050006行，測試果然不再出現上述問題，問題解決；并順勢延伸一下，以前用SAA7105做CVBS輸出時偶爾也會出現屏幕頂部顯示不正常問題應該與這個問題一樣，所以用上述相同的方法修改程序后對SAA7105 CVBS輸出進行強化測試（每8秒鐘重新啟動一次，強化測試3天），結果沒有再出現顯示不正常現象；
例6：同樣是PNX1700音視頻開發平臺上遇到的問題，VGA輸出時OSD菜單會抖動，最先想到的方法是把OSD的scaler改用QVCP來做而不是MBS來做，這樣在1500上會減輕 OSD抖動現象，幾乎不出，但在1700上測試效果還是很不好，抖動仍然很厲害，后來安排同事將1500種DDR時鐘的工作頻率從166MHz提高到 200MHz，并告訴他需要改哪個模塊的哪幾個寄存器，這時正好是用VGA做視頻輸出（一般情況是用CVBS做視頻輸出，但因為此時正在跟蹤VGA中 OSD抖動問題，所以用了VGA輸出模式）來調DDR工作頻率的，在同事修改DDR寄存器過程中我卻發現OSD怎么不抖了，仔細研究同時修改過的寄存器相關位的定義，發現在DDR模塊中有兩個寄存器與DDR仲裁相關，一個是ARB_HRT_WINDOW（0x65184，DDR仲裁硬件實時窗口），另一個是ARB_CPU_WINDOW（0x65188，DDR仲裁CPU窗口），將這兩個寄存器分別設置成ARB_HRT_WINDOW = 0xffff及ARB_CPU_WINDOW = 0x0就不會出現OSD抖動，因為在這種設置情況下DDR對DMA的占有權高于CPU對DDR的擁有權，DDR可以搶斷CPU，原來的設置使CPU可以搶斷DDR占有DMA。其實在發現問題VGA中的OSD抖動問題之初我也找過與memory相關的寄存器設置，因為根據以前經驗和習慣思維，DDR配置寄存器只是負責DDR部分，而memory與CPU之間關系的寄存器應該在系統寄存器中，所以沒有去查找DDR配置寄存器，可是在這一例子中卻偏偏在DDR配置寄存器中。
從上述幾個例子中我們可以總結歸納以下幾點調試方法和注意事項：
1）加深理解法：加深理解包括加深對硬件和軟件的理解，加深對硬件的理解主要是詳細閱讀相關的芯片數據手冊，而加深對軟件的理解是因為現在開發嵌入式系統并不是所有程序都需要自己編寫，很多都是已經做好的，直接從網上獲取或者采購獲得，但這些軟件不一定是完全針對我們自己的目標板的，所以在使用過程中經常會發現一些問題，特別是底層軟件，而一旦出現問題，開發人員首先必須了解出現問題的代碼。只有建立在對相關硬件和軟件深入理解的基礎上才可能做出更符合實際的判斷，才可能更好地解決問題。
2）比較法：比較的方法有很多，比如將同樣的軟件放在兩個類似但不相同的硬件平臺上運行比較現象；將兩個不同版本的軟件放在同一個硬件平臺上運行比較現象；將相同的軟件放到相同批次但不同的兩個硬件平臺上運行比較現象。對于一些不是很隱蔽的問題通過比較法通常能得到不錯的效果。
3）分解法：當碰到分析起來比較復雜、可能有很多因素的問題時，可以把問題分成解幾個小問題來測試診斷，比如編寫幾個單獨的小測試程序對各種可能因素進行排查測試，根據這些測試結果再進行科學判斷。
4）軟硬件結合法：這種方法是需要一定靈感和悟性的。比如上面的例5，在測試過程中，可以在不破壞硬件的前提下臨時改變一下硬件的狀態（比如該例中將數據線和時鐘線短路），看問題現象會不會有所變化，如果有，那么多做類似試驗找出變化規律和關鍵因素，然后再進行分析解決。在底層軟件開發中，對于時序要求嚴格的硬件模塊的軟件編程要特別注意，一旦程序的時序出了問題，而這部分軟件已經與其他系統軟件融合到一起，那么這種軟件讓別人去檢查是很難查出問題的。
5）診斷、排故要建立在大量實驗的基礎之上，要多動手，不能光知道臆想，不愿實際操作，還美其名曰“善于思考和分析”。嵌入式系統開發是一門實踐性很強的科學，需要在實踐中總結出事物客觀規律，從而更好地認識和利用它們，讓它們更好地按我們的意圖工作。
6）嵌入式系統開發調試要求開發人員有嚴謹細致的工作態度，決不放過調試過程中發現的任何一點蛛絲馬跡，因為它很可能就是打開潘多拉寶盒的鑰匙。
7）要有實事求是的工作作風，要有敢于懷疑一切的精神和勇氣，我們理當尊重權威和前人的科技成果，但當出現矛盾時我們更應該相信實驗結果，這樣科學才會進步。
8）要勇于挑戰自我，拋開習慣性思維和成見，拓寬思路，多角度分析問題。
9）嵌入式系統開發特別是底層軟件和操作系統內核開發因為需要同時跟軟件和硬件打交道，所以是一件比較艱苦的工作，很有挑戰性。即使我們各方面都做得非常好，考慮得非常細致周全，目標系統仍然可能跟我們開一些小小的玩笑，我們經常會碰到一個非常小的問題困擾我們幾天甚至幾周的時間，這期間我們可能茶飯不思、夜不能寐，因此嵌入式系統底層軟件開發人員不但要有平和的心態，且具備一定的耐心和毅力，還要有勇于克服一切困難的勇氣和信心！只要我們做得足夠好，那么可能解決一個具體疑難的過程帶有一定偶然性，但我們終將排除所有阻礙！
所以說，嵌入式系統調試過程就是一個更加深入了解我們的目標系統以及系統中的每個單元模塊特性的過程，就是一個鍛煉我們的邏輯思維和分析推理能力的過程，就是一個開拓思路、向習慣思維和權威挑戰的過程，就是一個培養嚴謹細致的工作態度和實事求是工作作風的過程，就是一個鍛煉我們耐力和毅力的過程，最終是一個學習進步的過程！
嵌入式系統調試診斷能力的提升是一個長期實踐、積累、提高的過程！
本文節選自王洪輝老師的《嵌入式系統Linux內核開發實戰指南（ARM平臺）》一書。