1. 問題描述：

最近在支持BLE KW客戶時就遇到一個很隱蔽的問題，讓我對ARM斷點又有了顛覆性的認識，此處聊作記錄，也為讀者分析問題提供一個思路。

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

2. 問題分析：

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

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

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

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

3. 斷點類型和實現(xiàn)原理分析

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

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

3.1 硬件斷點：

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

3.2 Flash斷點：

Flash斷點也就是本次問題的罪魁禍首了，也是從原理上來講最最容易出現(xiàn)問題的斷點。其實現(xiàn)原理是在設置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執(zhí)行修改的策略，譬如一個Sector地址區(qū)域的多個Flash斷點是執(zhí)行一次還是多次的Flash操作，以及Flash插入的斷點恢復策略等，需要使用時自行體會。

3.3 軟件斷點：

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

3.4 數(shù)據(jù)斷點：

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

4. 斷點實驗證明：

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

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

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

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運行的代碼軟件斷點在實現(xiàn)上本質也還是Flash斷點。

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

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中默認優(yōu)先使用硬件斷點，而當前debug中設置了6個軟件斷點，所以main出的斷點被自動分配為硬件斷點?？梢钥吹?，全部6個軟件斷點對應地址區(qū)域的值都被修改為了0xBE00，也就是前文提到的軟件斷點其實也變成了Flash斷點，main地址處內容沒有發(fā)生變化，符合預期。

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

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

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

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

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

6. 結論：

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

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

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

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

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

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

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

審核編輯：劉清