——為什么調試器會在運行中改我的Flash程序？

調試單片機時，很多人都有這樣的疑問：

明明我在調試前刷進去的固件是好的，為什么加了一個斷點之后，調試器居然去改了 Flash？
如果我拔掉調試器，這個固件還能正常跑嗎？

今天我們就來完整講一講**軟件斷點（Software Breakpoint）**的原理，以及它和 MCU Flash 之間的關系。

---

1. 什么是斷點？

調試器要讓程序在某一行停下來，有兩種方法：

斷點類型	原理	數量限制	速度	是否改寫代碼
硬件斷點	利用 MCU 內部的 FPB（Flash Patch and Breakpoint） 單元，在指令地址匹配時自動中斷	一般 4~6 個	極快	否
軟件斷點	直接把目標指令改成一條特殊的“陷阱指令”（如 BKPT）	理論無限（可寫內存）	RAM 中快，Flash 中慢	是

所以，ST-Link / J-Link / DAPLink 這些調試器本質上都一樣，只是硬件斷點數量受 MCU 限制，而軟件斷點理論上可以很多，但需要改寫代碼。

---

2. 軟件斷點的工作原理

以 ARM Cortex-M 為例，軟件斷點的流程是這樣的：

1. 下斷點
   調試器接收到“在地址 0x08001234 停下來”的指令。

2. 備份原指令
   從 MCU 讀出該地址的機器碼（2 字節或 4 字節），保存到調試器內存。

3. 寫入陷阱指令
   將該位置改成 BKPT #imm（機器碼通常是 0xBE00）。

4. 運行時觸發異常
   CPU 執行到 BKPT → 進入 Debug 模式 → 調試器接管。

5. 恢復原指令
   當你“移除斷點”或“單步執行”時，調試器把原機器碼寫回去。

關鍵點：

• 如果斷點地址在 RAM 中，直接寫就行，很快，也不會磨損。

• 如果斷點地址在 Flash 中，就必須擦除整頁 → 改一條指令 → 回寫整頁，這會稍微慢一些，還會增加 Flash 擦寫次數。

---

3. 為什么調試器會改 Flash？

因為軟件斷點就是修改原程序的一個過程。

• 硬件斷點不改代碼，但數量有限。

• 軟件斷點數量無限，但需要替換原來的指令為 BKPT。

• 在 Flash 中替換指令 → 必須擦寫 Flash。

這也解釋了兩個現象：

1. 加 Flash 斷點有延遲：那是擦寫 Flash 的時間（幾十到幾百微秒）。

2. 斷點太多可能會磨損 Flash：雖然調試時次數不多，但確實有寫入動作。

---

4. 調試結束后的風險

大多數調試器在結束調試時，會自動恢復原指令。
但在以下情況可能會殘留 BKPT：

• IDE / 調試器崩潰；

• 直接拔掉 USB / 斷電；

• 固件編譯時手動寫了 __BKPT()，且 Release 版沒屏蔽。

如果 BKPT 留在 Flash 里，MCU 在無調試器連接的情況下運行到這里：

• 會觸發 HardFault 或 Debug Monitor Exception；

• 如果程序沒有異常處理，就會直接死機。

---

5. 如何避免死機

1. 發布版本不用軟件斷點
   確保 Release 固件是干凈的，不帶調試指令。

2. 異常處理里跳過 BKPT
   在 HardFault Handler 中檢查指令，如果是 BKPT，就跳過它：

   void HardFault_Handler(void) {uint32_t *pc = (uint32_t *)__get_MSP();if (*(uint16_t *)(*pc) == 0xBE00) { // BKPT*pc += 2; // 跳過斷點指令return;}while (1); // 其他錯誤
   }
   

3. 調試結束前移除斷點
   養成好習慣，不要讓調試器崩潰時處于有斷點的狀態。

---

6. 總結

• 硬件斷點：靠 MCU 內部比較器實現，不改代碼，速度快但數量有限。

• 軟件斷點：通過改指令（RAM 直接寫，Flash 要擦寫）實現，數量無限但會改程序。

• 調試結束時如果 BKPT 沒被恢復，獨立運行可能直接死機。

• 最安全的做法是：發布固件前移除所有軟件斷點，并做好異常處理。