痞子衡嵌入式：IAR線上除錯時設不同復位型別可能會導致i.MXRT下除錯現象不一致(J-Link/DAPLink)

痞子衡發表於2020-09-15
除錯型別

　　大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是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主頁、知乎主頁、微信公眾號 平臺上。

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

相關文章