大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是IAR在線調試時設不同復位類型可能會導致i.MXRT下調試現象不一致。
做Cortex-M內核MCU嵌入式軟件開發，可用的集成開發環境(IDE)非常多。經典的GCC咱們就不提了，選擇不同MCU主控，如果MCU來自知名大廠，廠商也會配套推出專用IDE（比如恩智浦半導體的MCUXpresso IDE，意法半導體的TrueSTUDIO、STM32CubeIDE）。除此以外，還有幾個來自專門軟件公司的獨立IDE，比如Keil MDK、IAR EWARM。因為獨立IDE不與具體MCU廠商捆綁，並且為了保持商業上的競爭力，往往在性能和易用性上表現得更好，所以市場占有率居高不下。
痞子衡求學期間主要使用Keil MDK，參加工作后一直在用IAR EWARM，剛畢業的時候用的IAR版本是v6.50，七年過去了，如今IAR也發展到了v8.50，界面變得更漂亮了，功能也越發強大，所以底下痞子衡會陸續介紹IAR使用經驗小細節。痞子衡今天要講的是在線調試時的復位類型設置對i.MXRT調試執行的影響。
一、IAR調試機制
在講IAR調試中復位類型設置小細節前先給大家簡單介紹一下IAR的調試機制，下圖是典型的嵌入式開發調試硬件連接，首先你得有一塊MCU主控板，板子上要引出調試口（JTAG/SWD），然后你得有一個硬件仿真器（比如J-Link/DAPLink），通過仿真器將你的PC和MCU板連接起來，PC上用IAR打開你的應用程序工程，然后你就可以愉快地調試解bug了。
你應該知道MCU里內置了Cortex-M調試模塊，IAR借助硬件仿真器可以通過調試口與MCU調試模塊互動，收發調試數據。但是你知道IAR里是誰在負責調試功能嗎？是C-SPY，它是IAR內置的專用調試組件，你在調試時查看匯編代碼，修改變量數據，設斷點，單步，檢查call stack等功能全是它在后台默默完成的。下圖是C-SPY與所有潛在目標系統的聯合工作簡圖，其中藍色框標出來的方式適用我們常見的與J-Link/DAPLink聯合使用的場景：
C-SPY支持的硬件仿真器類型非常全，這都是通過設計對應的C-SPY驅動來實現的，不同的仿真器下支持的調試特性不同，具體可以查看 \IAR Systems\Embedded Workbench x.xx.x\arm\doc\EWARM_DebuggingGuide.ENU 文檔中的"Driver differences, I-jet, J-Link/J-Trace and ST-LINK"一表。
二、兩種調試分類(在Flash/在RAM)
在i.MXRT上根據應用程序代碼(read only段)鏈接位置所屬的存儲器性質，在線調試主要分為兩類：在外部Flash調試和在內部SRAM調試（在外部SDRAM/HyperRAM調試暫不在考慮范疇）。
因為外部Flash數據不能像內部SRAM上那樣直接寫入，需要調用額外的Flash下載算法才能寫入，因此C-SPY處理在Flash調試和在SRAM調試的流程有一些區別。
首先來看C-SPY處理在內部SRAM調試的流程，C-SPY調試器啟動后設置好合適的JTAG速度后便開始掛起目標板上的CPU（即MCU中Cortex-M內核），然后直接通過JTAG口和AHB總線往目標板上的MCU內部SRAM里寫入應用程序鏡像數據，寫完再進行可選的數據校驗和用戶Reset/Setup后便可以操控CPU開始執行SRAM里的應用程序。
再來看C-SPY處理在外部Flash調試的流程，C-SPY調試器掛起CPU后先是往MCU內部SRAM里加載了一個Flashloader程序（即Flash下載算法），然后讓CPU執行Flashloader來完成應用程序鏡像數據的Flash燒寫，燒寫完成之后再次掛起CPU，進行可選的數據校驗和用戶Reset/Setup后便操控CPU開始執行Flash里的應用程序。
你需要特別留意一下這兩張流程圖里可選的CPU reset動作，我們看到在SRAM調試流程中僅在寫入應用程序鏡像前有一次CPU reset，而在Flash調試流程中燒寫應用程序鏡像前后均有一次CPU reset動作，為什么在Flash調試需要多一次CPU reset？這是因為Flashloader程序會初始化MCU外設模塊（比如Clock，GPIO，FlexSPI等），這些初始化過的MCU外設模塊如果不復位到初始狀態可能會對后面應用程序的執行產生一定影響。
三、復位類型全解析
好了，現在我們進入正題，開始介紹復位類型，上一節講的CPU reset其實只是一個籠統的說法，其具體復位行為在IAR里是可配的。不同硬件仿真器下復位類型命名有差異，痞子衡主要介紹i.MXRT上兩種最常用的仿真器：J-Link和DAPLink。
3.1 Cortex-M7復位功能
不管是哪種仿真器，其都借助了Cortex-M7內核功能，內核在SCB模塊的AIRCR寄存器中集成了復位的支持。打開CM7的Generic User Guide手冊，可以找到如下AIRCR寄存器定義：
- VECTRESET：這種復位的作用范圍覆蓋整個CM7處理器中，除了調試邏輯之外的所有角落，但是它不會影響到CM7處理器外部的任何電路，所以MCU上的片上外設和其它電路都不受影響。
- SYSRESETREQ：這種復位則會波及整個芯片上的電路：它會使CM7處理器把送往系統復位發生器的請求線置為有效。但是系統復位發生器不是CM7的一部分，而是由芯片廠商實現，因此不同的芯片對此復位的響應也不同。
3.2 J-Link復位類型
- Normal（復位編號0）：默認的復位策略，對於i.MXRT來說等同於Core and peripherals方式
- Core（復位編號1）：借助Cortex-M內核模塊SCB中的AIRCR寄存器的VECTRESET位功能來復位Core
- Core and peripherals（復位編號8）：借助Cortex-M內核模塊SCB中的AIRCR寄存器的VECTRESET位和SYSRESETREQ位來同時復位Core和MCU外設模塊
- Reset Pin（復位編號2）：通過拉低J-Link的RESET引腳（一般也會接到MCU reset腳）來復位MCU
剩下幾種復位類型不適用i.MXRT，暫不介紹。
3.3 DAPLink復位類型
- Disabled (no reset)：顧名思義，沒有reset動作
- Software：直接將CPU的PC指針重置到應用程序入口函數，相當於軟復位
- Hardware：通過翻轉DAPLink的nSRST/nRESET引腳（一般也會接到MCU reset腳）來復位MCU
- Core：借助Cortex-M內核模塊SCB中的AIRCR寄存器的VECTRESET位功能來復位Core
- System：借助Cortex-M內核模塊SCB中的AIRCR寄存器的VECTRESET位和SYSRESETREQ位來同時復位Core和MCU外設模塊
剩下幾種復位類型在i.MXRT上意義不大，暫不介紹。
四、復位類型對在線調試的影響
復位類型對在線調試的影響分兩種：一、是否影響應用程序正常調試；二、是否影響應用程序正常運行。對於第二點，因為應用程序的設計差異，無法確定復位類型的不同導致的未復位片上外設對其產生何種影響，因此我們暫不討論這點，我們主要看第一點。
設置不同的復位類型是否影響應用程序正常調試（能否停在程序入口函數，能否進行單步）？痞子衡在MIMXRT1060-EVK上實測了SDK里的led_blinky例程，選取了debug（在SRAM）和flexspi_nor_debug（在Flash）兩個build做了很多組測試，結果如下：
| 例程Build | 仿真器 | 復位類型 | BootMode | 調試現象 |
|---|---|---|---|---|
| debug | J-Link DAPLink |
所有的 | 2'b01 - SDP 2'b10 - Flash Boot |
正常下載與調試 |
| flexspi_nor_debug | J-Link | - Core | 2'b01 - SDP 2'b10 - Flash Boot |
正常下載與調試 |
| flexspi_nor_debug | J-Link | - Normal - Core and peripherals - Reset Pin |
2'b01 - SDP | 正常下載，0x60000000處校驗失敗，無法調試 |
| flexspi_nor_debug | J-Link | - Reset Pin | 2'b10 - Flash Boot | 正常下載與調試 |
| flexspi_nor_debug | J-Link | - Normal - Core and peripherals |
2'b10 - Flash Boot | 正常下載，0x60000000處校驗警告，但能正常調試 |
| flexspi_nor_debug | DAPLink | - Disabled (no reset) - Software - Core |
2'b01 - SDP 2'b10 - Flash Boot |
正常下載與調試 |
| flexspi_nor_debug | DAPLink | - Hardware - System |
2'b01 - SDP | 正常下載，0x60000000處校驗失敗，無法調試 |
| flexspi_nor_debug | DAPLink | - Hardware | 2'b10 - Flash Boot | 正常下載與調試 |
| flexspi_nor_debug | DAPLink | - System | 2'b10 - Flash Boot | 正常下載，0x60000000處校驗警告，但能正常調試 |
從上表的測試結果，我們可以得到如下結論：
- 結論1：在SRAM調試，完全不受復位類型和芯片啟動模式影響（僅有掉電破壞SRAM里內容才可能影響調試）
- 結論2：在Flash調試，要想正常調試，要么不復位片上外設（保留Flashloader對FlexSPI等模塊的初始化），要么啟動模式設成Flash Boot（讓BootROM完成FlexSPI等模塊的初始化），因為Clock/GPIO/FlexSPI的初始化必須保留，CPU才能正常獲得Flash里指令
至此，IAR在線調試時設不同復位類型可能會導致i.MXRT下調試現象不一致現象痞子衡便介紹完畢了，掌聲在哪里~~~
歡迎訂閱
文章會同時發布到我的 博客園主頁、CSDN主頁、知乎主頁、微信公眾號 平台上。
微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
