大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是不同J-Link版本對于i.MXRT1170連接復位后處理行為。

痞子衡之前寫過一篇舊文 《i.MXRT1170上用J-Link連接復位后PC總是停在0x223104的原因》，這篇文章詳細解釋了 RT1170 BootROM 代碼里軟件實現的 Debug Mailbox 機制對 J-Link 調試體驗的影響，文末還給了結論 J-Link 里只要執行 reset 后 PC 就必定會停在 0x223014，這句話其實不完全準確，因為底層 J-Link 腳本內容可以改變這個行為，這在不同 J-Link 版本的 DLL 處理里就有體現。今天痞子衡要聊得就是這個話題：

一、不同J-Link版本關于RT1170更新

為了了解不同 J-Link 版本對于 RT1170 處理差異，痞子衡從 J-Link 歷史版本記錄 https://www.segger.com/downloads/jlink/ReleaseNotes_JLink.html 里抽取了從 V6.64 - V7.96i 所有關于 RT1170 更新如下，其中 V6.86、V6.94、V6.98c、V7.86 四個版本涉及 Debug 連接處理，但是沒有說明進一步實現細節。

二、J-Link V6.86f對于RT1170連接復位處理

從 J-Link 版本來看，V6.86 開始正式支持 RT1170 B0 Silicon（恩智浦最終發布的芯片版本），我們就從 V6.86 版本開始做測試。在測試之前，痞子衡在板載串行 NOR Flash 里燒錄了一個鏈接在 0x30002000 的 XIP App 程序。然后使用 J-Link commander 操作如下：

上述測試結果表明：當芯片上電/復位能正常啟動鏈接在 0x30002000 的 App 時，J-Link 下用默認 MIMXRT1176XXXA_M7 設備去連芯片復位后，PC 能停在 App 里，因為自帶 DLL 里集成了 jlinkscript 處理，這在 dll 里搜索 "Valid application detected. Setting PC / SP manually." 信息可知。但是如果我們自己添加的 jlinkscript 不包含這樣的處理（比如用超級下載算法 UFL），那么 PC 還是停在 0x223104。

如果我們在板載串行 NOR Flash 里燒錄了一個不是鏈接在 0x30002000 的 App，痞子衡燒錄得是鏈接在 0x3000a000 處的 XIP App（總之保證 Flash 偏移 0x2000 處沒有有效 App 中斷向量表），再來做同樣的測試（在芯片能正常啟動 App 情況下），此時 PC 永遠停在 0x223104，這說明 J-Link DLL 默認集成的 jlinkscript 永遠是從 Flash 0x2000 偏移處取 App 信息去設置 PC、SP。

我們緊接著上面的測試，使用 mem32 命令讀取 0x3000a000 處內容，發現是有效 App 數據，這說明 FlexSPI 外設被正常初始化了，此時手動設置 PC、SP 后可以跳轉到 App 里，這意味著如果我們自定義 jlinkscript 里能夠解析 IVT 去獲取 App 信息，那么可以做到通用。

三、不同J-Link版本對于RT1170連接復位處理

由于 V6.86 版本對于連接復位處理已經一定程度上滿足實際需求，因此對比后續更高 J-Link 版本意義不太重要了，不過這里有一個差異不得不提。正常來說，在芯片上電/復位能正常啟動鏈接在 0x30002000 的 App 情況下，reset 命令執行完后，PC 應該 halt 在 BootROM 里，需要繼續使用 go 命令才能跳轉進入 App，這在 V6.86 上確實如此。然后在 V7.94f 版本上測試來看，reset 之后，PC 已經 halt 在 App 里了。

至此，不同J-Link版本對于i.MXRT1170連接復位后處理行為痞子衡便介紹完畢了，掌聲在哪里~~~