痞子衡嵌入式：揭祕i.MXRT1170上用J-Link連線復位後PC總是停在0x223104的原因

痞子衡發表於2021-12-24

　　大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是i.MXRT1170上安全除錯策略實現對JLink除錯的影響。

　　痞子衡之前寫過一篇舊文 《i.MXRT600的ISP模式下用J-Link連線後PC總是停在0x1c04a》，這篇文章詳細解釋了 Debug Mailbox 機制對 J-Link 除錯體驗的影響。我們知道 Debug Mailbox 是 i.MXRT 三位數系列（i.MXRT500/600）獨有的外設模組，但是在 i.MXRT1170 上使用 J-Link 除錯似乎存在跟 i.MXRT 三位數系列下類似的體驗，這個體驗明顯跟 i.MXRT10xx 系列下不同，而且 i.MXRT1170 中沒有 Debug Mailbox 模組，這是怎麼回事？且聽痞子衡細聊：

一、引出除錯問題

　　按照我們之前在 i.MXRT1050 上的除錯經驗，將晶片設為序列下載模式後，使用 JLink 連線上晶片，並 halt 住核心，此時晶片 PC 是正常停在 ROM 區域的（不斷 go 和 halt 命令交替執行，PC 值是一直在變化的），讓我們同樣的過程在 i.MXRT1170 上也操作一次：

　　我們發現 PC 固定指向了 0x223104，並且不管你如何 reset 再重新 halt，它一直停在這個地方，這是怎麼回事？

二、ROM中除錯安全策略實現

　　不同於 i.MXRT 三位數系列中有專門暫存器 RSTCTRL0->SYSRSTSTAT[5] 記錄核心軟復位狀態（warm reset）以便 BootROM 初始化階段根據此狀態來進入 Debug Mailbox 安全除錯流程，在 i.MXRT1170 上是一種全新的方式，BootROM 利用了一個未開放的除錯中斷（中斷號 52），該除錯中斷被使能後，當除錯口接收到除錯請求時，該中斷便會被觸發。

　　i.MXRT1170 BootROM 初始化階段會立即使能這個 Reserved68_IRQn 中斷，並且用一個全域性變數（is_debug_pending）記錄該中斷觸發狀態。在 BootROM 執行過程中，一旦除錯中斷觸發，在其中斷響應函式裡會將 is_debug_pending 置起來，並且立刻關閉 Reserved68_IRQn 中斷（不需要二次響應），然後 BootROM 兩個主階段（ Serial Downloader 和 Device Boot）流程裡都會有對 is_debug_pending 狀態的處理，只要 is_debug_pending 被置起來，BootROM 就會立即結束正常主流程，轉而做一些安全化的處理（HAB狀態清理、恢復時鐘/外設、中斷相關狀態善後），最後便進入如下 debug_loop_routine() 函式，__ASM("B .") 指令地址就在 0x223104，這就是 i.MXRT1170 上的除錯安全設計，其實是一種簡化的 Debug Mailbox 機制。

#define LPSR_GPR41 (*(volatile uint32_t *)0x40c0c0a4)

void debug_loop_routine(void)
{
    while (!(LPSR_GPR41 & (1ul << 24)));
    register uint32_t dummy = OCOTP->VERSION;

#if (defined(__ICCARM__))
    __ASM("B .");
#endif
}

三、安全策略對JLink除錯的影響

　　基於上面分析，最後痞子衡再總結一下這個安全策略對 JLink 除錯的影響：

  1. 當晶片在ROM中執行（比如SDP模式，比如Flash中沒有應用程式）時，用JLink連線晶片，halt住核心，PC總是停在0x223104，這是安全除錯策略決定的。
  2. 當晶片正常啟動Flash裡的應用程式後（即離開了ROM），用JLink連線晶片，halt住核心，PC指向的是真實的應用程式位置。
  3. 當JLink連線上晶片後，只要執行reset命令，都會直接進入安全除錯模式（PC停在0x223104）。

　　至此，i.MXRT1170上安全除錯策略實現對JLink除錯的影響痞子衡便介紹完畢了，掌聲在哪裡~~~

歡迎訂閱

文章會同時釋出到我的 部落格園主頁、CSDN主頁、知乎主頁、微信公眾號 平臺上。

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

相關文章