痞子衡嵌入式：MCUXpresso IDE下在線調試時使用不一樣復位策略的現象總結

---

　　你們好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給你們分享的是MCUXpresso IDE下在線調試時使用不一樣復位策略的現象總結。

　　本篇其實是《IAR在線調試時設不一樣復位類型可能會致使i.MXRT下調試現象不一致》的同系列篇，計劃中痞子衡是要把幾大經典IDE（IAR EWARM、Keil MDK、MCUXpresso IDE）下的復位策略都寫一遍，但一直沒抽出時間。今天痞子衡剛好幫助一位印度同事解決了在客戶板子上使用MCUXpresso在線調試的問題，所以順便認真研究了下MCUXpresso IDE下復位策略，特意分享給你們。

　　在讀本文前，最好把痞子衡先前寫過的一篇 《MCUXpresso IDE下使用J-Link下載算法在Flash調試注意事項》 瀏覽一下，本文要探討的問題比先前那篇文章要更深刻。

• Note: 痞子衡測試的MCUXpresso IDE版本是v11.3.0_5222。

1、在客戶板卡上遇到的調試問題

　　先來回顧下客戶遇到的調試問題。據印度同事介紹，客戶本身設計的i.MXRT1052板卡，使用的Flash是Cypress生產的S25FL128LAGMFI01，客戶寄了一塊樣卡給我同事，我同事在客戶板卡上隨便找了個SDK裏的hello world工程（MCUXpresso IDE）去在線調試，調試器是恩智浦的LPC-Link2。

　　i.MXRT1050 SDK工程裏默認選擇的下載算法是適用官方EVK上默認Hyper Flash的，並不適用客戶這塊板卡上的QSPI Flash，所以印度同事爲客戶製做了一個LinkServer Flash Driver（MCUX下載算法），使用這個新制做的下載算法能夠去下載（至少從MCUX的下載日誌裏能夠看到Flash Write Done），可是斷點沒能停在main函數，所以沒法單步調試，並且在IDE裏檢查0x60000000處空間，看到的是以下無效數據，就像是程序根本沒有下載進去，這究竟是怎麼回事？痞子衡接下來就先爲你們分析MCUXpresso IDE下復位策略，最後再給你們解謎。

　　關於LinkServer Flash Driver的製做可參考痞子衡以前寫過的 《串行NOR Flash下載算法(MCUXpresso IDE篇)》，但其實這個客戶選擇的S25FL128LAGMFI01就是塊普通的符合JEDEC SFDP標準的QSPI NOR，在MCUXpresso IDE安裝目錄下的MIMXRT1050_SFDP_QSPI.cfx算法是能夠直接使用的（路徑是 \MCUXpressoIDE_11.3.0_5222\ide\binaries\Flash）。

2、MCUXpresso IDE調試機制與調試分類

　　關於MCUXpresso IDE下的調試機制原理在 \MCUXpressoIDE_11.3.0_5222\MCUXpresso_IDE_User_Guide.pdf 手冊裏並無找到設計性的介紹，雖然手冊裏一共有以下四個章節涉及到了下載調試，但更可能是介紹如何在IDE裏使用下載調試功能。

10. Debug Solutions Overview
11. Debugging a Project
14. The GUI Flash Tool
15. LinkServer Flash Support

　　不過調試機制在各IDE上大同小異，設計理念都是一致的，這部分建議參考 《IAR在線調試時設不一樣復位類型可能會致使i.MXRT下調試現象不一致》 裏的1、二章節。

3、復位類型全解析

　　好了，如今咱們進入正題，開始介紹MCUXpresso IDE下復位類型。咱們知道不一樣硬件仿真器下復位功能有差別，痞子衡主要介紹i.MXRT上兩種最經常使用的仿真器：J-Link和DAPLink。此外不論是哪一種仿真器，其都藉助了Cortex-M7內核功能，內核在SCB模塊的AIRCR寄存器中集成了復位的支持，詳見 《IAR在線調試時設不一樣復位類型可能會致使i.MXRT下調試現象不一致》 的 3.1 Cortex-M7復位功能 小節。

3.1 J-Link復位類型

　　MCUXpresso IDE下設置J-Link復位類型一共有以下圖所示三處，其本質上都是藉助Jlink底層命令，具體可在 \SEGGER\JLink_V686f\Doc\Manuals\UM08001_JLink.pdf 文檔中的 Supported remote (monitor) commands 小節裏的reset命令以及 List of available commands 小節裏的SetResetType命令裏找到詳細解釋。

　　UM08001_JLink.pdf 文檔中的 7.10.2 Strategies for Cortex-M devices 小節一共列出了以下三種復位類型：

• Normal（復位編號0）：默認的復位策略，對於i.MXRT來講等同於Core and peripherals方式
• Core（復位編號1）：藉助Cortex-M內核模塊SCB中的AIRCR寄存器的VECTRESET位功能來複位Core
• Reset Pin（復位編號2）：經過拉低J-Link的RESET引腳（通常也會接到MCU reset腳）來複位MCU

　　上圖復位類型設置框中的三處設置，雖然都能使能復位操做，可是階段不一樣，其中紅框2處設置是的下載前操做，紅框3處設置是下載後的操做，紅框1處設置是執行前的操做。若是你對這個順序不瞭解，能夠作個試驗，好比咱們在紅框3處設置復位類型1，在紅框1處設置復位類型2，進入調試後在日誌窗口找到JLinkServer日誌，在日誌中查看具體順序。

　　在實際使用中，痞子衡推薦不使能紅框1中的"Reset before running"選項，而且僅在紅框3中設置復位類型，經測試這種方式與其餘IDE下的調試體驗最一致。但仍是有以下兩點注意事項：

• Note1: 復位命令後，必須增長一個monitor reg pc設置，不然沒法正常調試。
• Note2: 復位類型是0的狀況下，若是此時BootROM沒能正常啓動App（即應該不能正常調試），但在IDE界面裏有時候仍是會停在main函數，這實際上是假象（應該跟cache有關），並不能正常調試，點擊suspend按鈕就能看到跑飛。

3.2 LinkServer復位類型

　　LinkServer即對應DAPLink調試器，是MCUXpresso IDE默認的調試器類型，IDE裏爲這個默認調試器實現了友好的復位類型選項。

　　上圖復位類型設置紅框1中的「Reset handling」一共提供了五種復位選擇。這五種復位除了SOFT外，其他都不會主動設PC指針，默認全靠breakpoint去觸發調試。

• Default：等同於於SYSRESETREQ方式
• SYSRESETREQ：藉助Cortex-M內核模塊SCB中的AIRCR寄存器的SYSRESETREQ位來同時復位MCU外設模塊
• VECTRESET：藉助Cortex-M內核模塊SCB中的AIRCR寄存器的VECTRESET位功能來複位Core
• SOFT：直接將CPU的PC指針重置到應用程序入口函數，至關於軟復位
• 空：等同於SYSRESETREQ方式

　　同上節JLink復位類型同樣，LinkServer下也提供了額外的Commands設置（紅框2/3），具體命令寫法需查看 MCUXpresso_IDE_User_Guide.pdf 手冊，本文就不詳細介紹了。

　　關於Reset handling選擇SOFT方式的結果，有一點須要特別指出，咱們在以下對應日誌裏能夠看到，下載完成後調用了soft reset而且從0x60000000處拿了SP和PC，即MCUXpresso IDE認爲下載首地址就是程序中斷向量表起始地址，這個假定在i.MXRT的XIP工程上實際上是不成立的，咱們知道正確的中斷向量表起始地址應該是0x60002000。如想讓MCUXpresso IDE拿到正確的SP/PC，應該在XIP工程預編譯選項裏把XIP_BOOT_HEADER_ENABLE設成0（也能夠研究下在紅框3中增長LinkServer命令去設置PC），不然無法正常調試。

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

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

　　設置不一樣的復位類型是否影響應用程序正常調試（可否停在程序入口函數，可否進行單步）？痞子衡在MIMXRT1050-EVKB上實測了SDK裏的led_blinky例程，選取了flexspi_nor_debug（在Flash）build作了不少組測試，結果以下：

例程Build	仿真器	復位類型	BootMode	調試現象
flexspi_nor_debug	J-Link	monitor reset 1	2'b01 - SDP 2'b10 - Flash Boot	正常下載與調試
flexspi_nor_debug	J-Link	monitor reset 0/2	2'b01 - SDP	正常下載，沒法調試
flexspi_nor_debug	J-Link	monitor reset 0/2	2'b10 - Flash Boot	正常下載與調試
flexspi_nor_debug	LinkServer	- SOFT	2'b01 - SDP 2'b10 - Flash Boot	正常下載與調試，注意程序不能含XIP頭
flexspi_nor_debug	LinkServer	- 除SOFT外其他四種	2'b01 - SDP	正常下載，沒法調試
flexspi_nor_debug	LinkServer	- 除SOFT外其他四種	2'b10 - Flash Boot	正常下載與調試

　　從上表的測試結果，咱們能夠獲得以下結論：

• 結論1：在Flash調試，要想正常調試，要麼不復位片上外設（保留Flashloader對FlexSPI等模塊的初始化），要麼啓動模式設成Flash Boot（讓BootROM完成FlexSPI等模塊的初始化），由於Clock/GPIO/FlexSPI的初始化必須保留，CPU才能正常得到Flash裏指令。
• 結論2：JLink復位下，MCUXpresso IDE調試體驗與其餘IDE是一致的。
• 結論3：LinkServer復位下，MCUXpresso IDE下VECTRESET方式復位達不到其餘IDE下同等方式的效果，由於初始PC沒法獲得。

5、客戶板卡上調試問題的緣由

　　最後回到客戶板上的問題，痞子衡的印度同事實際上是很是有經驗的，板卡啓動模式設置，Flash下載算法，工程裏的FDCB頭所有都是正確的，可是經查明板卡i.MXRT1052芯片的eFuse中BOOT_CFG2[3]位被燒寫成了1，即芯片進入了inifnite loop模式，PC永遠停在BootROM裏，客戶App不會被啓動，所以沒法硬復位後進調試。

　　BootROM中系統初始化函數裏對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: SystemInit\n");

    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下在線調試時使用不一樣復位策略的現象總結痞子衡便介紹完畢了，掌聲在哪裏~~~

歡迎訂閱

文章會同時發佈到個人 博客園主頁、CSDN主頁、知乎主頁、微信公衆號 平臺上。

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