1. 前言

2. 常用斷點存在的問題

3. IAR支持的斷點類型和使用方法

3.1. 代碼斷點

3.2 條件代碼斷點

3.3 讀寫訪問的數據斷點

3.4 數據日志斷點

3.5 日志斷點

3.6 電源斷點

4. 總結：

5. 經驗交流：

1. 前言在產品開發中，調試工具是不可或缺的開發利器，除了日常常見的ARM的CMSIS-DAP/ULINK，IAR的I-JET，P&E的U-multilink/Cyclone， 各個半導體廠商自定義的XX-LINK（例如LPC-link， ST-Link，等）之外，還有兩個是神一樣的存在，一個是SEGGER的J-LINK，支持與IAR/KEIL等各種編譯環境無縫銜接，性能穩如老狗， 價格低廉， 所以在嵌入式工程師中的普及率非常高，被稱為居家旅行匱贈好友之佳品。另外一個是一聽名字就感覺高大上的勞特巴赫Lauterbach，作為專業第三方調試工具廠商，以其強大的TRACE32開發調試工具享譽全球，TRACE32開發工具擁有非常豐富和強大的功能，包括基本調試配置、RTOS、多核系統、虛擬目標調試、能耗分析以及強大的腳本語言等，而且可以支持市場中使用的80多種常見的微處理架構。

當然Lauterbach性能的強大，對應的代價就是價格也比JLINK多出一個數量級，但是對于大部分嵌入式開發者來說，最常用的還是基本的調試功能，包括斷點，寄存器查看，內存/Flash的查看，本文從斷點使用的角度講解如何使用JLINK配合IAR支持的各種斷點用出點勞德巴赫的一些強大功能。

2. 常用斷點存在的問題斷點的概念非常簡單，目的簡單來說就是在指定指令或者代碼行中斷程序的執行，實現上可以是硬件斷點（通過編程FPB實現）也可以是軟件斷點（通過插入BKPT斷點指令實現 ），具體二者的底層實現這里不展開討論。常規的斷點調試（本質上是代碼斷點）是在想觀察哪里的問題時就在對應的代碼地址雙擊設置斷點，并且一旦運行到斷點位置會讓程序自動暫停運行，然后觀察感興趣的變量，內存或者寄存器，這種斷點調試功能能幫助開發者解決大部分的問題，但是其也有很大的局限性。

因為很多時候我們只想知道某段代碼是否運行過，而不能讓程序停下來，譬如說調試BLE協議棧，無法去單步運行，否則會打斷BLE主機和從機之間的通訊時序，而導致整個系統功能出現問題。還有中斷處理函數的調試，程序一旦停下了也就失去了其他所有中斷的后續響應，再比如兩個設備通信，一旦一方采用常規斷點的方式調試，可能會打斷正常的通信過程。所以通常的做法是添加串口打印或者ITM半主機打印輸出log信息到顯示屏，但是這種方式會帶來額外的軟硬件開銷（對于串口打印來說是兩個UART pin腳+UART驅動函數，對于ITM打印輸出是一個SWO+ITM驅動），甚至因為引入新的代碼導致程序出錯。除此之外，還有3種場景是這種普通斷點無法滿足的，第一個是同一段循環體運行N次才停下來，第二個是當變量被寫入新的數據或者被讀取時停下來，第三個是實時記錄斷點所在行某個特定變量或者地址的值，并在時間軸上以圖形的形式顯示出來，方便分析和對比。

以上這些功能在這些功能在勞德巴赫中是最基本功能，同樣在IAR中也提供了不同形式的斷點類型和組合，只是日常習慣了只用了其代碼斷點的功能，沒能充分發揮IAR的強大斷點功能，針對以上4種問題在IAR中可以分別用日志斷點、條件斷點、讀寫權限的數據斷點、數據日志斷點逐個擊破，從而避免了額外添加代碼的繁瑣，也能為解決隱藏bug提供更加靈活的手段。尤其是其中的讀寫權限的數據斷點，筆者曾經就是使用這種辦法幫客戶解決了兩個埋藏的很深大bug，其中一個是查找某個關鍵變量在哪里被意外修改，通過設置條件斷點+stack callback迅速定位到了肇事代碼段，另一種是客戶代碼意外堆棧溢出調查，當時的做法是在堆棧大小的90%地址靠近棧頂處設置一個寫觸發的數據斷點，當某層調用過程中堆棧接近溢出時，設置的數據斷點會被觸發而停止應用程序，從而迅速找到堆棧是在哪層調用溢出的，從而解決問題。

3. IAR支持的斷點類型和使用方法總結下來，在 IAR 中，主要有以下幾種斷點，下面逐一介紹。

代碼斷點

條件斷點

讀寫訪問權限的數據斷點

數據日志斷點

日志斷點

電源斷點

3.1. 代碼斷點

這種斷點就是前面提到的最常用的斷點，也是最簡單的斷點。開發則只需要在反匯編窗口中選擇C行或ASM指令并切換斷點。一旦遇到斷點，用戶應用程序將停止。這時候可以查看變量、標志和寄存器的值。換句話說，開發者擁有完全的控制權。對于這種普通代碼斷點，其數量受限于硬件斷點的數量，例如對于 Arm Cortex-M，通常有6-8個硬件斷點，但如果使用軟件斷點或在RAM中運行應用程序，則可以不受限制。使用時只需選擇顯示View -》 Breakpoints 窗口，就可以啟用或禁用斷點。

默認情況下，IDE 將設置代碼斷點，而且是auto類型，可以通過Option-》Debugger-》JLINK/JTrace-》Breakpoint去設置硬件斷點還是軟件斷點。如果開發者有 I-jet，可以在右鍵單擊代碼行時明確選擇一個 flash斷點。注意斷點符號中的“F”。Flash 斷點功能在適用于 Arm 的IAR7.60 或更高版本中可用。

3.2 條件代碼斷點

條件斷點是代碼斷點與某些標志或變量作為條件的組合。設置斷點后，同樣可以再次使用View -》 Breakpoints 窗口查看所有斷點，也可以通過右鍵單擊并選擇Edit option來設置額外參數。

設置斷點條件所使用的語法類似于C語法，可以使用 ==、》= 和 《=。例如，如果您希望應用程序在計數器等于 10 時在斷點處停止，您可以使用“counter==10”。這在中斷例程中需要斷點時非常有用。如果沒有設置條件，應用程序就會一直被停止，影響到系統的正常工作，使用標志或變量作為條件使事情變得容易得多。甚至用戶還可以使用跳過計數器和條件檢查（如true或changed）來實現更復雜的斷點停止條件設置。該方法可以解決上面提到的第二種問題。

3.3 讀寫訪問的數據斷點

與其他斷點相比，數據斷點有點不同，因為是對特定內存地址、標志、變量或寄存器的讀寫訪問的監控。使用時只需右鍵單擊標志或變量并選擇選項Set data Breakpoint。默認情況下，對該變量，特定地址，寄存器的任何讀取和寫入訪問都會觸發斷點。如果你想添加額外的設置，你可以通過View-》Breakpoints 窗口和Edit 選項來完成。 除了讀寫訪問之外，還可以監控數據是否匹配來作為斷點的觸發條件，這意味著寫或讀訪問只會在數據匹配時觸發暫停。另外，通過選擇編輯按鈕，開發者還可以打開一個額外的窗口，可以選擇絕對地址甚至源代碼所在行。對于變量或標志，建議使用自動大小。如果需要監控更大的范圍，則應手動設置監控的地址范圍或者變量范圍，譬如說監控一個結構體的數據變化，使用這種數據斷點也是可以實現的，但需要用戶正確設置變量，特定地址，寄存器等監控對象的Size。使用這種方法可以解決前文提到的第三種問題。

此處需要特別提一下，數據斷點對于調試被應用程序破壞的標志和變量非常有用。筆者曾經就是使用這種辦法在客戶解決了兩個埋藏的很深大bug，其中一個是查找某個關鍵變量在哪里被意外修改，通過設置條件斷點+stack callback迅速定位到了肇事代碼段，另一種是客戶端的意外堆棧溢出調查，當時的做法是在堆棧大小的90%地址靠近棧頂處設置一個數據斷點，當堆棧溢出接近時，設置的數據斷點會被觸發而停止應用程序，從而迅速找到問題的根源，至于如何設置，此處暫不展開。

3.4 數據日志斷點

除了具有讀寫訪問權限的數據斷點外，開發者還可以使用數據日志斷點。這種斷點的好處在于可以在時間線中監視和以圖形方式繪制內存中特定變量或地址的值，使顯示更加直觀，用戶還可以在同一個時間軸上顯示和比較兩個或多個變量，從而在邏輯上排查問題。設置的方法就是View-》Breakpoints 窗口和Edit 選項，然后選擇set Data Log Breakpoint for counter即可，使用這種方法可以解決前文提到的第四種問題。

時間線以及附加數據日志和數據日志摘要可在探針選項下找到，例如如下面的屏幕截圖所示。

3.5 日志斷點

除了代碼和數據斷點之外，還有一種日志斷點，這是一個特殊的斷點，因為它只會臨時暫時停止應用程序以打印消息，然后繼續代碼的運行。一旦運行到設置的日志斷點，它會顯示如下用戶預先設定的消息，告知用戶某個函數事件被觸發。這種方式的好處在于，無需額外添加串口打印或者ITM半主機打印輸出log信息到顯示屏，無需額外的軟硬件開銷，便可實現基本的信息打印，方便開發者跟蹤程序的執行流程。

如下圖所示，每次斷點命中時，調試日志窗口中都會顯示一條消息。添加的計數器可以了解應用程序通過該部分源代碼的次數。通過這種辦法可以解決前面提到的第一個問題，即不停止代碼又能獲知感興趣的代碼段是否被執行過，以及執行的次數，兵不血刃，無需添加任何額外的代碼。

3.6 電源斷點

除了代碼的調試，IAR還支持先進的電源調試技術，可以監控功耗，并將其與源代碼相關聯。這也使得添加電源斷點成為可能，可以設置一個閾值，如 25mA，一旦能量高于該值，調試器將被觸發停止。設置閾值非常簡單， 只需要打開J-Link-》PowerLog 窗口，然后設置值和所需選項，如上圖或下圖所示。通過這種分析，可以直觀的看出代碼執行過程中的功耗值，下面的時間線窗口不是必需的，但它可以為提供正在使用的能量提供一個時間參考。

4. 總結：至此，介紹完了IAR支持的6種不同的斷點類型和使用方法，也順帶針對性的解決了前文中提到的日常調試遇到的四個問題。如果在日常調試過程中靈活運用以上的這幾種斷點，對于日常調試提高開發速度和解決一些深藏的bug（例如前文提到的大型程序中變量被莫名修改，堆棧溢出追蹤等） 很有幫助。當然勞特巴赫之所以賣的這么貴，必然有其強大之處，尤其是強大的腳本編程，多核系統，能耗分析以及對芯片內部操作的開放度，能給開發者最大的操作靈活度。但就日常的斷點調試看，IAR+JLINK的組合也基本能滿足大部分的需求，畢竟就地取材最方便。

責任編輯：haq