痞子衡嵌入式:MCUXpresso IDE下線上除錯時使用不同復位策略的現象總結

痞子衡 發表於 2021-04-07

  大家好,我是痞子衡,是正經搞技術的痞子。今天痞子衡給大家分享的是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。

一、在客戶板卡上遇到的除錯問題

  先來回顧下客戶遇到的除錯問題。據印度同事介紹,客戶自己設計的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下復位策略,最後再給大家解謎。

痞子衡嵌入式: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)。

二、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下除錯現象不一致》 裡的一、二章節。

三、復位型別全解析

  好了,現在我們進入正題,開始介紹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命令裡找到詳細解釋。

痞子衡嵌入式:MCUXpresso IDE下線上除錯時使用不同復位策略的現象總結

  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日誌,在日誌中檢視具體順序。

痞子衡嵌入式:MCUXpresso IDE下線上除錯時使用不同復位策略的現象總結

  在實際使用中,痞子衡推薦不使能紅框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裡為這個預設偵錯程式實現了友好的復位型別選項。

痞子衡嵌入式:MCUXpresso 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),否則沒法正常除錯。

痞子衡嵌入式:MCUXpresso IDE下線上除錯時使用不同復位策略的現象總結

四、復位型別對線上除錯的影響

  復位型別對線上除錯的影響分兩種:一、是否影響應用程式正常除錯;二、是否影響應用程式正常執行。對於第二點,因為應用程式的設計差異,無法確定復位型別的不同導致的未復位模組對其產生何種影響,因此我們暫不討論這點,我們主要看第一點。

  設定不同的復位型別是否影響應用程式正常除錯(能否停在程式入口函式,能否進行單步)?痞子衡在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無法得到。

五、客戶板卡上除錯問題的原因

  最後回到客戶板上的問題,痞子衡的印度同事其實是非常有經驗的,板卡啟動模式設定,Flash下載演算法,工程裡的FDCB頭全部都是正確的,但是經查明板卡i.MXRT1052晶片的eFuse中BOOT_CFG2[3]位被燒寫成了1,即晶片進入了inifnite loop模式,PC永遠停在BootROM裡,客戶App不會被啟動,因此無法硬復位後進除錯。

痞子衡嵌入式:MCUXpresso IDE下線上除錯時使用不同復位策略的現象總結

  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主頁知乎主頁微信公眾號 平臺上。

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

痞子衡嵌入式:MCUXpresso IDE下線上除錯時使用不同復位策略的現象總結

相關文章