芯耀
143
大家好，我是痞子衡，是正經(jīng)搞技術的痞子。今天痞子衡給大家分享的是MCUXpresso IDE下在線調(diào)試時使用不同復位策略的現(xiàn)象總結(jié)。
本篇實際上是《IAR在線調(diào)試時設不同復位類型可能會導致i.MXRT下調(diào)試現(xiàn)象不一致》的同系列篇，計劃中痞子衡是要把幾大經(jīng)典IDE（IAR EWARM、Keil MDK、MCUXpresso IDE）下的復位策略都寫一遍，但一直沒抽出時間。今天痞子衡恰好幫助一位印度同事解決了在客戶板子上使用MCUXpresso在線調(diào)試的問題，因此順便認真研究了下MCUXpresso IDE下復位策略，特地分享給大家。
在讀本文前，最好把痞子衡先前寫過的一篇 《MCUXpresso IDE下使用J-Link下載算法在Flash調(diào)試注意事項》 瀏覽一下，本文要探討的問題比先前那篇文章要更深入。
- Note: 痞子衡測試的MCUXpresso IDE版本是v11.3.0_5222。
一、在客戶板卡上遇到的調(diào)試問題
先來回顧下客戶遇到的調(diào)試問題。據(jù)印度同事介紹，客戶自己設計的i.MXRT1052板卡，使用的Flash是Cypress生產(chǎn)的S25FL128LAGMFI01，客戶寄了一塊樣卡給我同事，我同事在客戶板卡上隨便找了個SDK里的hello world工程（MCUXpresso IDE）去在線調(diào)試，調(diào)試器是恩智浦的LPC-Link2。
i.MXRT1050 SDK工程里默認選擇的下載算法是適用官方EVK上默認Hyper Flash的，并不適用客戶這塊板卡上的QSPI Flash，因此印度同事為客戶制作了一個LinkServer Flash Driver（MCUX下載算法），使用這個新制作的下載算法可以去下載（至少從MCUX的下載日志里可以看到Flash Write Done），但是斷點沒能停在main函數(shù)，因此無法單步調(diào)試，而且在IDE里檢查0x60000000處空間，看到的是如下無效數(shù)據(jù)，就像是程序根本沒有下載進去，這到底是怎么回事？痞子衡接下來就先為大家分析MCUXpresso IDE下復位策略，最后再給大家解謎。
關于LinkServer Flash Driver的制作可參考痞子衡之前寫過的 《串行NOR Flash下載算法(MCUXpresso IDE篇)》，但其實這個客戶選擇的S25FL128LAGMFI01就是塊普通的符合JEDEC SFDP標準的QSPI NOR，在MCUXpresso IDE安裝目錄下的MIMXRT1050_SFDP_QSPI.cfx算法是可以直接使用的（路徑是 MCUXpressoIDE_11.3.0_5222idebinariesFlash）。
二、MCUXpresso IDE調(diào)試機制與調(diào)試分類
關于MCUXpresso IDE下的調(diào)試機制原理在 MCUXpressoIDE_11.3.0_5222MCUXpresso_IDE_User_Guide.pdf 手冊里并沒有找到設計性的介紹，雖然手冊里一共有如下四個章節(jié)涉及到了下載調(diào)試，但更多是介紹如何在IDE里使用下載調(diào)試功能。
10. Debug Solutions Overview
11. Debugging a Project
14. The GUI Flash Tool
15. LinkServer Flash Support
不過調(diào)試機制在各IDE上大同小異，設計理念都是一致的，這部分建議參考 《IAR在線調(diào)試時設不同復位類型可能會導致i.MXRT下調(diào)試現(xiàn)象不一致》 里的一、二章節(jié)。
三、復位類型全解析
好了，現(xiàn)在我們進入正題，開始介紹MCUXpresso IDE下復位類型。我們知道不同硬件仿真器下復位功能有差異，痞子衡主要介紹i.MXRT上兩種最常用的仿真器：J-Link和DAPLink。此外不管是哪種仿真器，其都借助了Cortex-M7內(nèi)核功能，內(nèi)核在SCB模塊的AIRCR寄存器中集成了復位的支持，詳見 《IAR在線調(diào)試時設不同復位類型可能會導致i.MXRT下調(diào)試現(xiàn)象不一致》 的 3.1 Cortex-M7復位功能 小節(jié)。
3.1 J-Link復位類型
MCUXpresso IDE下設置J-Link復位類型一共有如下圖所示三處，其本質(zhì)上都是借助Jlink底層命令，具體可在 SEGGERJLink_V686fDocManualsUM08001_JLink.pdf 文檔中的 Supported remote (monitor) commands 小節(jié)里的reset命令以及 List of available commands 小節(jié)里的SetResetType命令里找到詳細解釋。
UM08001_JLink.pdf 文檔中的 7.10.2 Strategies for Cortex-M devices 小節(jié)一共列出了如下三種復位類型：
- Normal（復位編號0）：默認的復位策略，對于i.MXRT來說等同于Core and peripherals方式Core（復位編號1）：借助Cortex-M內(nèi)核模塊SCB中的AIRCR寄存器的VECTRESET位功能來復位CoreReset Pin（復位編號2）：通過拉低J-Link的RESET引腳（一般也會接到MCU reset腳）來復位MCU
上圖復位類型設置框中的三處設置，雖然都能使能復位操作，但是階段不同，其中紅框2處設置是的下載前操作，紅框3處設置是下載后的操作，紅框1處設置是執(zhí)行前的操作。如果你對這個順序不了解，可以做個試驗，比如我們在紅框3處設置復位類型1，在紅框1處設置復位類型2，進入調(diào)試后在日志窗口找到JLinkServer日志，在日志中查看具體順序。
在實際使用中，痞子衡推薦不使能紅框1中的"Reset before running"選項，并且僅在紅框3中設置復位類型，經(jīng)測試這種方式與其他IDE下的調(diào)試體驗最一致。但還是有如下兩點注意事項：
- Note1: 復位命令后，必須增加一個monitor reg pc設置，否則無法正常調(diào)試。Note2: 復位類型是0的情況下，如果此時BootROM沒能正常啟動App（即應該不能正常調(diào)試），但在IDE界面里有時候還是會停在main函數(shù)，這其實是假象（應該跟cache有關），并不能正常調(diào)試，點擊suspend按鈕就能看到跑飛。
3.2 LinkServer復位類型
LinkServer即對應DAPLink調(diào)試器，是MCUXpresso IDE默認的調(diào)試器類型，IDE里為這個默認調(diào)試器實現(xiàn)了友好的復位類型選項。
上圖復位類型設置紅框1中的“Reset handling”一共提供了五種復位選擇。這五種復位除了SOFT外，其余都不會主動設PC指針，默認全靠breakpoint去觸發(fā)調(diào)試。
同上節(jié)JLink復位類型一樣，LinkServer下也提供了額外的Commands設置（紅框2/3），具體命令寫法需查看 MCUXpresso_IDE_User_Guide.pdf 手冊，本文就不詳細介紹了。
關于Reset handling選擇SOFT方式的結(jié)果，有一點需要特別指出，我們在如下對應日志里可以看到，下載完成后調(diào)用了soft reset并且從0x60000000處拿了SP和PC，即MCUXpresso IDE認為下載首地址就是程序中斷向量表起始地址，這個假定在i.MXRT的XIP工程上其實是不成立的，我們知道正確的中斷向量表起始地址應該是0x60002000。如想讓MCUXpresso IDE拿到正確的SP/PC，應該在XIP工程預編譯選項里把XIP_BOOT_HEADER_ENABLE設成0（也可以研究下在紅框3中增加LinkServer命令去設置PC），否則沒法正常調(diào)試。
四、復位類型對在線調(diào)試的影響
復位類型對在線調(diào)試的影響分兩種：一、是否影響應用程序正常調(diào)試；二、是否影響應用程序正常運行。對于第二點，因為應用程序的設計差異，無法確定復位類型的不同導致的未復位模塊對其產(chǎn)生何種影響，因此我們暫不討論這點，我們主要看第一點。
設置不同的復位類型是否影響應用程序正常調(diào)試（能否停在程序入口函數(shù)，能否進行單步）？痞子衡在MIMXRT1050-EVKB上實測了SDK里的led_blinky例程，選取了flexspi_nor_debug（在Flash）build做了很多組測試，結(jié)果如下：
| 例程Build | 仿真器 | 復位類型 | BootMode | 調(diào)試現(xiàn)象 |
|---|---|---|---|---|
| flexspi_nor_debug | J-Link | monitor reset 1 | 2'b01 - SDP 2'b10 - Flash Boot |
正常下載與調(diào)試 |
| flexspi_nor_debug | J-Link | monitor reset 0/2 | 2'b01 - SDP | 正常下載，無法調(diào)試 |
| flexspi_nor_debug | J-Link | monitor reset 0/2 | 2'b10 - Flash Boot | 正常下載與調(diào)試 |
| flexspi_nor_debug | LinkServer | - SOFT | 2'b01 - SDP 2'b10 - Flash Boot |
正常下載與調(diào)試，注意程序不能含XIP頭 |
| flexspi_nor_debug | LinkServer | - 除SOFT外其余四種 | 2'b01 - SDP | 正常下載，無法調(diào)試 |
| flexspi_nor_debug | LinkServer | - 除SOFT外其余四種 | 2'b10 - Flash Boot | 正常下載與調(diào)試 |
從上表的測試結(jié)果，我們可以得到如下結(jié)論：
- 結(jié)論1：在Flash調(diào)試，要想正常調(diào)試，要么不復位片上外設（保留Flashloader對FlexSPI等模塊的初始化），要么啟動模式設成Flash Boot（讓BootROM完成FlexSPI等模塊的初始化），因為Clock/GPIO/FlexSPI的初始化必須保留，CPU才能正常獲得Flash里指令。結(jié)論2：JLink復位下，MCUXpresso IDE調(diào)試體驗與其他IDE是一致的。結(jié)論3：LinkServer復位下，MCUXpresso IDE下VECTRESET方式復位達不到其他IDE下同等方式的效果，因為初始PC無法得到。
五、客戶板卡上調(diào)試問題的原因
最后回到客戶板上的問題，痞子衡的印度同事其實是非常有經(jīng)驗的，板卡啟動模式設置，F(xiàn)lash下載算法，工程里的FDCB頭全部都是正確的，但是經(jīng)查明板卡i.MXRT1052芯片的eFuse中BOOT_CFG2[3]位被燒寫成了1，即芯片進入了inifnite loop模式，PC永遠停在BootROM里，客戶App不會被啟動，因此無法硬復位后進調(diào)試。
BootROM中系統(tǒng)初始化函數(shù)里對BOOT_CFG2[3]位的處理代碼：
volatile uint32_t infinite_loop;
void SystemInit (void)
{
#if ((__FPU_PRESENT == 1) && (__FPU_USED == 1))
SCB->CPACR |= ((3UL << 10*2) | (3UL << 11*2)); /* set CP10, CP11 Full Access */
#endif /* ((__FPU_PRESENT == 1) && (__FPU_USED == 1)) */
TRACE("BootROM: SystemInitn");
rtwdog_disable();
/* Below codes is used for issue troubleshooting on real chip */
if ((ROM_OCOTP_INFINITE_LOOP_VALUE() == 1) && (ROM_OCOTP_DIR_BT_DIS_VALUE() == 0))
{
infinite_loop = 1;
while(infinite_loop)
{
}
}
// 代碼省略
}
至此，MCUXpresso IDE下在線調(diào)試時使用不同復位策略的現(xiàn)象總結(jié)痞子衡便介紹完畢了，掌聲在哪里~~~
