痞子衡嵌入式：IAR在線調試時設不一樣復位類型可能會致使i.MXRT下調試現象不一致(J-Link/DAPLink)

---

　　你們好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給你們分享的是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調試執行的影響。

1、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"一表。

2、兩種調試分類(在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外設模塊若是不復位到初始狀態可能會對後面應用程序的執行產生必定影響。

3、復位類型全解析

　　好了，如今咱們進入正題，開始介紹復位類型，上一節講的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上意義不大，暫不介紹。

4、復位類型對在線調試的影響

　　復位類型對在線調試的影響分兩種：1、是否影響應用程序正常調試；2、是否影響應用程序正常運行。對於第二點，由於應用程序的設計差別，沒法肯定復位類型的不一樣致使的未復位片上外設對其產生何種影響，所以咱們暫不討論這點，咱們主要看第一點。

　　設置不一樣的復位類型是否影響應用程序正常調試（可否停在程序入口函數，可否進行單步）？痞子衡在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主頁、知乎主頁、微信公衆號 平臺上。

微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就能夠在手機上第一時間看了哦。