嵌入式開發中難免出現這樣或那樣的問題， 因而軟件的調試手段會直接影響到開發的進度， 本節將總結一些常用的調試方法：
(1) 聯機調試
對於在操作系統上（windows 或Linux)運行的內核態程序可以通過windbg或kgdb進行調試， 對於規模小一些的開發板也可以用JTAG調試器進行調試。
該方法適用於軟件開發初期的流程調試， 但缺點如下：
a. 對於小概率的Bug, 有時很難聯機跟蹤
b. 某些硬件功能與時序相關， 聯機和導致bug無法復現或硬件超時
c. 反覆執行一段時間後纔出現的問題， 雖然可以在錯誤分支設斷點， 但可能是積累性（即最終錯誤時前面錯誤積累導致的)
d. 系統死機或失靈
（2） 基於日誌的調試
設計分級的日誌輸出機制，輸出的信息多少可以通過開關控制。 調試時可打開相應輸出開關， 根據出錯點的log向前分析。
該方法要求設計好日誌輸出格式，與控制標誌。 最好將該機制在軟件設計階段就確定下來。對於一些較小型的設備可以通過網絡, 串口將log輸出到上位機。
對於一些對代碼szie有限制的嵌入式設備，因爲空間限制需要對輸出信息進行編碼以減少size.
該方法的缺點如下：
a. 小型嵌入式系統由於代碼size限制，輸出信息可能較少，只能啓到輔助作用，這時需要結合其它方法調試。
b. 日誌設計不足， 無法定位問題
c. 突然死機等問題， 日誌輸出不完整
(3) 基於日誌的調試升級方法
基於日誌的調試的一個變種是將一部分重要日誌存到一片內存環形緩衝區中，出錯時可查看該內存區域。 該方法適用於叫底層的體系結構代碼和對時序要求較高的嵌入式模塊。log輸出甚至可以是一個我幾個led燈。
基於日誌調試的另一個變種就是Verify,在程序中建立檢查點， Debug版本可以開啓該功能. 一旦檢查點未通過則dump 出系統調用與狀態信息.
Verify的內容可以是軟件條件，或硬件狀態， 還可以是堆棧的檢查等較底層功能。
基於操作系統的項目還可以通過系統層的lon或信息來進行調試， 如windows 的ETW, Linux下其他模塊的log輸出。
(4)輔助工具調試
如調試協議相關軟件可以通過抓包軟硬件， 如tcp/ip包， usb協議包等。
調試硬件時序可採用示波器甚至邏輯分析儀。
調試內存泄露，可採用分析軟件。
(5) dump 信息分析
對於windows或Linux下的一些嚴重錯誤爲產生系統dump文件， 這時需要對dump進行分析。 對於幾層的驅動程序， 也可以在出錯點讓操作系統生成dump這樣有利於全局調試。
(6) 對比分析法
某些bug是由於一些case我們未處理好而造成的，但有時由於一些侷限性，在自身的測試平臺上未能發現這些問題； 且通過其他方法未能發現問題， 這時 可以對比自身平臺與能復現的平臺的差異性（軟件或硬件), 來推斷可能的原因。
(6) 代碼審查
代碼審查也是一種調試方法，自己的代碼有時自己難以發現問題， 可以請他人或小組討論的形式進行(也可使用自動代碼檢查工具)， 2類問題較容易通過該方法發現：
a.低級錯誤
b. 未處理的異常case
(7) 猜測驗證法
對於原因不易定位的問題， 可以通過提出一些懷疑點，並每次修改一個懷疑點；逐一排查的方法。 這種方法在萬不得已時可以使用， 帶最終最好找到根本原因。
下面是一些需要學習的調試相關的技能
(1) Arch相關的調試， 如硬件斷點，cpu branch記錄等。 爲此需要了解CPU級的調試機制（可通過Cpu spec)學習
(2) 理解調試器的的基本工作原理
(3) 調試器的使用如gdb, windbg等
(4) Dump文件的分析方法
最後推薦基本關於軟件調試的書籍 <<軟件調試>> （偏windows） <<軟件調試修煉之道>>(思考方法) 《DebugHacks中文版》(偏Linux）