1. 問題描述：

最近好久沒做筆記了，期間收到的很多后臺問題留言以及新的粉絲關注，感覺花時間碼的這些文字還是有用戶在認真閱讀的，節省了不少重復勞動。似乎每個夏季到了，離譜撞腦門子的問題就會變多，尤其一些車上的偶發問題復現難度很大甚是令人上頭，盡管分析過程中很花時間和精力，但是深究下去感覺還是收獲頗多。最近在支持BLE KW客戶時就遇到一個很隱蔽的問題，讓我對ARM斷點又有了顛覆性的認識，此處聊作記錄，也為讀者分析問題提供一個思路。

客戶在同一批次的KW36板子上燒錄同樣的代碼，都可以正常運行，但有幾塊板子會莫名其妙Hard fault，而且這幾塊板出現Hard fault的地點各不相同，其中一塊KW36板子是在收到某個固定UDS診斷服務執行處理時出現Hard fault，而且一旦問題出現該板子一直能重復復現問題。借助之前的一篇舊文《KW36 MCU Hard Fault問題查找和破解方法》通過Attach方式在Ozone IDE(Segger 出品的一個Debug神器)中連接上去Debug，很快查到導致Hard fault問題現場(沒白瞎之前花時間研究，大有一番練就打狗棒法，終于遇到一條狗的喜出望外)，發現每次出錯的位置都在同一行C代碼，仔細檢查該段代碼只是個平淡無奇的一個函數調用，檢查過stack空間也確認沒有溢出，那為何會出錯呢？同樣的代碼為何只有這幾個板子出錯呢？

2. 問題分析：

本著花里胡哨的問題都是隱藏在最樸實無華角落的真理，去對比了下兩者的匯編(實際上是真的沒啥思路)，偶然發現在Attach到問題板分別執行全速運行到出錯代碼行和單步運行到出錯代碼行時，兩者匯編竟然差異。如下圖右側是正常執行Attach到芯片得到的匯編代碼，左邊是出錯時的匯編代碼，發現出問題時匯編竟然出現了DC16和CDP2。DC16對應常量聲明，顯然DC16不應該在此處出現，CDP2是協處理器數據處理指令，KW36作為一個單核芯片，肯定無協處理器，更談不上協處理器指令。

考慮到上述的調試操作都是在Attach方式，不存在因為代碼下載導致Flash內容被修改的可能，那可能只有兩個：IDE解析錯誤以及代碼被意外修改，顯然前者是個死胡同，無從查起。于是順著第二條路Dump芯片內二進制(左側)和原始二進制文件(右側)對比發現兩者Flash確實有差異。如下圖所示，F000的值被修改成了BE00，同時處理CRC校驗值也被修改，So什么原因導致Flash被修改了呢？

以前有概念說斷點會程序代碼做修改，但這個二進制碼的修改如何和斷點扯上關系呢？于是開始了漫長的Google/Bing/度娘/ARM各種文檔里面輪番挖呀挖呀挖，直到挖出Cortex-M3權威指南中提到如下一句"BKPT 指令的機器碼是 0xBE00"，頓時豁然開朗，坐實了斷點導致Flash內容被修改。

可新的問題來了，斷點是如何修改到這段Flash內容的呢？什么類型的斷點會修改Flash？斷點改了Flash內容為何不會被還原？打斷點要注意什么才能保證修改后的Flash內容被正確還原？打軟件斷點是否會修改Flash內容？Flash斷點，硬件斷點以及程序斷點的區別？芯片明明寫著支持2個breakpoint，為何同一個IDE配合不同的調試工具實際上可以打出的斷點個數有差異？帶著一堆問號繼續探尋...

3. 斷點類型和實現原理分析

斷點的實現原理網上有很多介紹，大致意思都是說在程序運行的某個地方提前設置一個停止操作，CPU運行到該位置之后就會自動暫停，此時開發者就可以查看CPU寄存器的工作狀態。可這里的”設置一個停止操作“是如何實現的呢？又意味著什么呢？網上找到的都是基于X86的實現細節介紹，針對ARM的實現細節找了半天也都是語焉不詳。發揮絕知此事要躬行的精神(客戶需要復現現場)，筆者使用JLINK/I-JET+IAR在KW38 demo板子上做了一番測試，得出幾個很有意思的結論，完全顛覆了以前對斷點的一些認識，此處先拋出結論。

根據IDE和調試器的不同，斷點類型也被分為很多種包括硬件斷點、軟件斷點、Flash斷點、數據斷點、程序斷點、條件斷點、代碼斷點以及Trace斷點等。從實現原理上來講，一共有四大類：硬件斷點、軟件斷點、數據斷點以及Flash斷點，因為程序斷點和代碼斷點從原理上講可以歸屬于硬件斷點或者Flash斷點(具體哪一種取決于控制器支持的硬件斷點個數)，條件斷點屬于數據斷點，Trace斷點是結合Trace工具的程序斷點。下面分別深入介紹這四種斷點的實現機制：

3.1 硬件斷點：

硬件斷點需要MCU內部支持，其數量一般是有限的，具體取決于芯片廠商的實現，對應KW38、KW45、S32K1以及S32K3斷點支持個數統計如下表所示。從實現原理上講硬件斷點是通過FPB模塊來實現的，盡管這塊是芯片廠商自行實現的，但是ARM架構已為其分配固定的地址區域，如下圖紅色方框。所以不論哪個公司的cortex芯片，用戶都可以通過該地址查看已設置的硬件斷點所在地址。FPB提供了兩個功能：斷點功能和Flash地址重載, Flash地址重載是其一個高階功能，此處用到的是其斷點功能。當在程序中設置了硬件斷點后，該斷點處的地址就會被寫入到FPB的存儲區域，即E000_2000 – E000_3FFF區域，當CPU訪問該地址時，因為該地址在FPB中已經注冊過，硬件就會自動觸發一個斷點事件。

3.2 Flash斷點：

Flash斷點也就是本次問題的罪魁禍首了，也是從原理上來講最最容易出現問題的斷點。其實現原理是在設置Flash斷點時，IDE和仿真器會配合修改控制器Flash上的內容，進一步說就是將斷點處的指令修改為斷點指令0xBE00，相應地就會牽涉到對Flash的擦除和編程操作。由于Flash內容是非易失的，所以有可能在調試器意外斷開后對Flash斷點處插入的斷點指令還保留著，在用戶復位直接運行程序可能就會導致程序無法正常運行。

目前市場上各種宣稱支持Unlimited Breakpoint無限斷點的仿真器采用的就是這個原理，如下截圖的JLINK工具。需要提出的是Flash斷點不是任意仿真器+IDE的組合都支持的，需要IDE和仿真器配合起來，譬如Ozone/Embeded Studio配合JLINK，IAR需要配合I-JET才能在斷點設置時指定使用Flash斷點，如果IAR配合JLINK只能選擇軟件斷點(實際使用的其實也是Flash斷點，只是標注上不帶F標記)。I-JET和JLINK在支持Flash斷點的差別主要是對Flash執行修改的策略，譬如一個Sector地址區域的多個Flash斷點是執行一次還是多次的Flash操作，以及Flash插入的斷點恢復策略等，需要使用時自行體會。

3.3 軟件斷點：

軟件斷點最開始主要用于RAM中設置斷點，它的實現機制是將RAM中原有的指令替換為一個斷點指令，當CPU執行到該指令之后就會自動暫停，這個時候調試器便會將原有的指令放回原來位置。這個過程都是調試器自動實現的，對RAM的更新速度很快，所以用戶一般覺察不到。但實際情況是現在很多MCU受限于RAM大小，程序都是存放在Flash區域的，所以當斷點大于硬件斷點數量后，即便新的斷點選成軟件斷點，很多時候也會被設置為Flash斷點，意味著Flash斷點有的問題在使用軟件斷點時也需要注意，這也是為何將軟件斷點的講解放在Flash斷點之后。

3.4 數據斷點：

數據斷點又稱為條件斷點，在ARM內核手冊上稱為watchpoint斷點，是在CPU對特定地址訪問時會觸發的一種斷點，在芯片內部實現上需要DWT和FPB共同配合完成，在設置斷點的時候可以設置觸發的條件，比如對特定地址的讀訪問還是寫訪問。這種斷點對于追蹤堆棧溢出相關的問題有奇效。數據斷點同樣需要硬件支持，數量一般也是有限的，如對應KW38、KW45、S32K1以及S32K3數據斷點支持個數統計如下表所示。

4. 斷點實驗證明：

為了證明以上觀點，筆者在KW38板子上做了一系列的測試如下：

4.1 IAR+I-JET 強制使用2個Flash斷點，無硬件斷點：

如下截圖可以看到，在匯編和memory窗口中的數據都是原始的binary文件，但是通過額外的JLINK同時去Attach上去讀取可以看到對應0x16996地址和0x169A0物理地址的數據已經被修改為了0xBE00;此處要特別鳴謝下IAR的Wen hao兄給的啟發，確實沒想到IARMemory窗口讀取的數據和匯編窗口的指令居然都是假數據。

Note: IAR需要配合IAR公司自己的I-JET才能選擇Flash斷點，如果選擇JLINK等其他工具只能設置軟件斷點；

4.2 IAR+JLINK 使用2個硬件斷點+1個Flash斷點：

如下圖1 可以看到，兩個硬件斷點地址0x1FA2以及0x1FA6都被注冊到了FPB寄存器的0xE0002000地址了。要指出的是，此處提到的Flash斷點在IAR中顯示為軟件斷點，因為IAR中默認僅支持使用I-JET的工具去打Flash斷點，其標志就是會在紅點里面顯示一個F圖標。所以這也就是前文說到的，對于Flash運行的代碼軟件斷點在實現上本質也還是Flash斷點。

下圖2 可以看到，強制設置為line 38和line40處為硬件斷點之后，因為KW38只支持2個硬件斷點，main處這個斷點就被強制設定為了Flash斷點，分別去讀取0x1F98, 0x1FA2以及0x1FA6地址的值，可以看到main處斷點所在的地址內容被修改為了0xBE00，0x1FA2以及0x1FA6地址是正常的原始數據，存儲在硬件斷點地址，完全符合預期。

4.3 IAR+JLINK使用2個硬件斷點+2個軟件斷點：

可以看到，line36，line40被強行設置為硬件斷點，line38被設置為軟件斷點，main斷點也自動被分配為了軟件斷點，對比0x1F98, 0x1F9A, 0x1FA2, 0x1FA6地址的內容，只有0x1F98，0x1FA2兩個軟件斷點地址處的內容被修改為了0xBE00，即插入BKPT指令。0x1F9A和0x1FA6兩個硬件地址的內容沒有被修改，再次證明軟件斷點對于在Flash調試的控制器，本質上就是Flash斷點。

4.4 IAR+JLINK 使用6個軟件斷點+1個硬件斷點：

因為IAR中默認優先使用硬件斷點，而當前debug中設置了6個軟件斷點，所以main出的斷點被自動分配為硬件斷點。可以看到，全部6個軟件斷點對應地址區域的值都被修改為了0xBE00，也就是前文提到的軟件斷點其實也變成了Flash斷點，main地址處內容沒有發生變化，符合預期。

5. 如何預防Flash斷點帶來的潛在風險

對于硬件斷點和數據斷點來說，他們是基于寄存器的實現，脫離Debug狀態無法繼續生效，不會影響用戶代碼的脫機運行。但是Flash斷點因為牽涉到修改非易失的Flash數據，就有風險導致程序意外被修改無法運行，譬如說突然斷電，不合理退出debug狀態等。

而且對于該類問題，如果斷點斷在main函數的主任務上還容易觀察到，因為代碼很直觀的無法運行，而如果斷在了某個不常調用的但又會用到的子任務的某個switch case中，就容易埋下隱蔽的bug（本案例遇到的就是這個狀況）。還一種情況是實車現場分析過程中，常用的一種方式就是Attach觀察分析問題，如果使用到Flash斷點(尤其是Flash運行的軟件斷點)，且退出時沒注意清除該類型斷點，可能會帶來新的潛在問題。

設置完Flash斷點，對于突然斷電這種方式，自然是無解的，只能重新下載代碼。而在debug狀態時如何退出才是最優雅的方式(還原原本Flash內容)呢？筆者使用IAR+JLINK在KW38 demo板上上做了一系列測試，結論如下；

總的來說，為了避免Flash斷點帶來的Flash修改后沒有恢復的問題，需要在退出Debug模式時，先delete掉所有斷點，再去stop debug，或者先在在breakpoint窗口中Disable 所有Flash斷點后，再debug狀態下執行一次SW reset，讓Flash恢復回來，前者的缺點是下次debug時原來的斷點都丟失了，需要重新設置，優點是更徹底。

6. 結論：

基于以上分析可以得出幾個結論：

Flash斷點是會修改到Flash內容的，而且IDE和匯編中是體現不出該變化的，比較隱蔽；

Flash斷點導致Flash內容修改后未恢復的問題需要尤其重視，需要在退出debug前按章節5的兩種辦法加以處理；

軟件斷點對于非RAM中調試來說，IAR配合Jlink使用時本質上也是Flash斷點；

不是所有的調試器都支持Flash斷點，當設置的斷點個數超過硬件斷點個數，就會提示無法設置新的斷點，例如CMSIS DAP； 硬件斷點的支持個數有限，會在調試時默認采用，超過硬件斷點個數后的斷點JLINK默認會采用Flash斷點, IJET提示超過上限，需要選擇Flash斷點，斷點小紅點標志帶有F標志；

IAR+JLINK中JLINK支持Flash斷點是JLINK仿真器和其驅動的支持，IAR+IJET支持Flash斷點是IAR工具+I-JET硬件的支持，和IAR+JLINK的區別是其可以直接設置Flash類型斷點；

如果是Flash斷點打在了主函數導致重啟后代碼無法運行倒容易排查，如果是不小心打在了某個不常調用的子函數分支上，而功能測試時覆蓋度如果不夠，就可能導致埋下一個潛在的隱患；

審核編輯：湯梓紅