搞軟件開發，如果誰能拍胸脯說自己開發的代碼不存在bug，一定會被現實打臉的。系統復雜了，代碼多了，一定會出問題。就算代碼架構設計得多么先進，程序員編程水平多么高，團隊協作多么緊密，代碼審核多么嚴謹，運行出問題的幾率一定存在，是不過是概率大小，出問題早晚，問題的嚴重與否而已。

既然代碼會出問題，那肯定要解決，最有效的辦法就是調試（Debug）了。不管是嵌入式開發，還是應用開發，調試都是程序員必備技能，只不過嵌入式開發的調試又有所不同，除了需要OCD、GDB之類的調試軟件之外，還需要J-Link、ST-Link等調試器，以及片上JTAG模塊的支持。

我在讀大學的時候學的是51單片機，當時也只有實驗室有實驗箱。所謂的調試基本就是根據運行現象去分析，比如某種亮燈狀態表示某種情況，或者是串口打印信息，屏幕顯示信息等，以此來Debug。

后來跟課題組做項目，陸續用到AVR、PIC單片機，當時基本沒有第三方的開發板，只能找官方資源，官方的下載器。官方的調試器極其昂貴，想調試的話也只能跟調試51一樣，基本都能解決問題，就是要麻煩一點。

現在的ARM調試器都是白菜價，各個IDE也都具備基本的調試功能，Debug更方便了。Keil下的調試比較直觀，在工程選項里配置好調試參數后，點個按鈕就進入調試模式，這里就不多介紹。今天來講一下CubeIDE下怎么去調試代碼。

1. CubeIDE的編譯選項

跟Keil不同，基于Eclipse的CubeIDE下的工程默認有Debug和Release兩個編譯配置，如下圖所示。可以在工程屬性下設置不同的編譯參數，分別作為調試和發行時使用，當然也可以根據需要增加新的編譯配置。Keil下也可以實現類似的功能，不過需要我們自己去配置，這個有很多文檔可以參考。

保留不同編譯配置的功能在寫代碼時非常有用，結合條件編譯，可以提高調試效率，或者是適應不同的硬件平臺，不需要再搞一個新的工程。例如在Debug編譯配置下，默認會定義一個DEBUG的符號，在Release編譯配置下，則沒有定義這個符號。見下圖。

我們在編寫代碼的時候，就可以根據編譯配置的不同，結合條件編譯，選擇編譯不同的代碼。例如，在正常工作的時候，某個傳感器上電后需要經過10分鐘才能正常工作，而在調試的時候，完全沒必要去等這10分鐘。我們可以用下面的偽代碼實現這個功能。

#ifndef DEBUG
 delay_second(10*60);    //延時10分鐘
 #endif

2. 調試配置

使用Debug編譯選項編譯完成后，會在工程目錄->Debug下生成elf可執行文件，elf文件包含調試信息，這是我們調試的必要文件。Eclipse調試前需要配置調試參數，配置方式見下圖。

需要進行調試的話，點擊工具欄小蟲子圖標就進入調試模式。

在調試模式下可以設置斷點，或單步運行，也可以查看寄存器的值，變量值等。另外CubeIDE還提供了很多有用的功能，比如說可以調出“故障分析器”，代碼出現異常時可以自動分析錯誤類型，不需要我們費力的去查看相關寄存器的值來確定錯誤類型；還可以顯示反匯編后的匯編代碼，與C代碼同步顯示。需要注意的是，調試模式下，編譯代碼應選擇不優化，這樣設置的斷點才都會有效。

調試時所需要查看的信息都可以在下圖的菜單里調出來。

3. 小結

進入調試模式后，就可以根據實際情況設置斷點，查看寄存器或變量值，也可以根據需要單步運行。大家可以在實踐中熟悉調試方法與技巧。

另外，在調試模式下，無論是打斷點還是單步運行，都沒有辦法實時跟蹤寄存器或變量值，看到的只是斷點處的值，如果想看到實時變化的寄存器或變量值，甚至是某個函數被調用的次數，或者運行占用的CPU時間等，可以通過ARM提供的SWV（Serial Wire Viewer）實時跟蹤技術來實現，下次我們再來講講這個SWV。