不同J-Link版本对于i.MXRT1170连接复位后处理行为

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是不同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连接复位后处理行为痞子衡便介绍完毕了，掌声在哪里~~~