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