不同复位类型设置对IAR在线调试有何影响？

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家分享的是 IAR 在线调试时设不同复位类型可能会导致 i.MXRT 下调试现象不一致。

做 Cortex-M 内核 MCU 嵌入式软件开发，可用的集成开发环境(IDE)非常多。经典的 GCC 咱们就不提了，选择不同 MCU 主控，如果 MCU 来自知名大厂，厂商也会配套推出专用 IDE（比如恩智浦半导体的 MCUXpresso IDE，意法半导体的 TrueSTUDIO、STM32CubeIDE）。除此以外，还有几个来自专门软件公司的独立 IDE，比如 Keil MDK、IAR EWARM。因为独立 IDE 不与具体 MCU 厂商捆绑，并且为了保持商业上的竞争力，往往在性能和易用性上表现得更好，所以市场占有率居高不下。

痞子衡求学期间主要使用 Keil MDK，参加工作后一直在用 IAR EWARM，刚毕业的时候用的 IAR 版本是 v6.50，七年过去了，如今 IAR 也发展到了 v8.50，界面变得更漂亮了，功能也越发强大，所以底下痞子衡会陆续介绍 IAR 使用经验小细节。痞子衡今天要讲的是在线调试时的复位类型设置对 i.MXRT 调试执行的影响。

一、IAR 调试机制

在讲 IAR 调试中复位类型设置小细节前先给大家简单介绍一下 IAR 的调试机制，下图是典型的嵌入式开发调试硬件连接，首先你得有一块 MCU 主控板，板子上要引出调试口（JTAG/SWD），然后你得有一个硬件仿真器（比如 J-Link/DAPLink），通过仿真器将你的 PC 和 MCU 板连接起来，PC 上用 IAR 打开你的应用程序工程，然后你就可以愉快地调试解 bug 了。

你应该知道 MCU 里内置了 Cortex-M 调试模块，IAR 借助硬件仿真器可以通过调试口与 MCU 调试模块互动，收发调试数据。但是你知道 IAR 里是谁在负责调试功能吗？是 C-SPY，它是 IAR 内置的专用调试组件，你在调试时查看汇编代码，修改变量数据，设断点，单步，检查 call stack 等功能全是它在后台默默完成的。下图是 C-SPY 与所有潜在目标系统的联合工作简图，其中蓝色框标出来的方式适用我们常见的与 J-Link/DAPLink 联合使用的场景：

C-SPY 支持的硬件仿真器类型非常全，这都是通过设计对应的 C-SPY 驱动来实现的，不同的仿真器下支持的调试特性不同，具体可以查看 \IAR Systems\Embedded Workbench x.xx.x\arm\doc\EWARM_DebuggingGuide.ENU 文档中的"Driver differences, I-jet, J-Link/J-Trace and ST-LINK"一表。

二、两种调试分类(在 Flash/ 在 RAM)

在 i.MXRT 上根据应用程序代码(read only 段)链接位置所属的存储器性质，在线调试主要分为两类：在外部 Flash 调试和在内部 SRAM 调试（在外部 SDRAM/HyperRAM 调试暂不在考虑范畴）。

因为外部 Flash 数据不能像内部 SRAM 上那样直接写入，需要调用额外的 Flash 下载算法才能写入，因此 C-SPY 处理在 Flash 调试和在 SRAM 调试的流程有一些区别。

首先来看 C-SPY 处理在内部 SRAM 调试的流程，C-SPY 调试器启动后设置好合适的 JTAG 速度后便开始挂起目标板上的 CPU（即 MCU 中 Cortex-M 内核），然后直接通过 JTAG 口和 AHB 总线往目标板上的 MCU 内部 SRAM 里写入应用程序镜像数据，写完再进行可选的数据校验和用户 Reset/Setup 后便可以操控 CPU 开始执行 SRAM 里的应用程序。

再来看 C-SPY 处理在外部 Flash 调试的流程，C-SPY 调试器挂起 CPU 后先是往 MCU 内部 SRAM 里加载了一个 Flashloader 程序（即 Flash 下载算法），然后让 CPU 执行 Flashloader 来完成应用程序镜像数据的 Flash 烧写，烧写完成之后再次挂起 CPU，进行可选的数据校验和用户 Reset/Setup 后便操控 CPU 开始执行 Flash 里的应用程序。

你需要特别留意一下这两张流程图里可选的 CPU reset 动作，我们看到在 SRAM 调试流程中仅在写入应用程序镜像前有一次 CPU reset，而在 Flash 调试流程中烧写应用程序镜像前后均有一次 CPU reset 动作，为什么在 Flash 调试需要多一次 CPU reset？这是因为 Flashloader 程序会初始化 MCU 外设模块（比如 Clock，GPIO，FlexSPI 等），这些初始化过的 MCU 外设模块如果不复位到初始状态可能会对后面应用程序的执行产生一定影响。

三、复位类型全解析

好了，现在我们进入正题，开始介绍复位类型，上一节讲的 CPU reset 其实只是一个笼统的说法，其具体复位行为在 IAR 里是可配的。不同硬件仿真器下复位类型命名有差异，痞子衡主要介绍 i.MXRT 上两种最常用的仿真器：J-Link 和 DAPLink。

3.1 Cortex-M7 复位功能

不管是哪种仿真器，其都借助了 Cortex-M7 内核功能，内核在 SCB 模块的 AIRCR 寄存器中集成了复位的支持。打开 CM7 的 Generic User Guide 手册，可以找到如下 AIRCR 寄存器定义：

• VECTRESET：这种复位的作用范围覆盖整个 CM7 处理器中，除了调试逻辑之外的所有角落，但是它不会影响到 CM7 处理器外部的任何电路，所以 MCU 上的片上外设和其它电路都不受影响。SYSRESETREQ：这种复位则会波及整个芯片上的电路：它会使 CM7 处理器把送往系统复位发生器的请求线置为有效。但是系统复位发生器不是 CM7 的一部分，而是由芯片厂商实现，因此不同的芯片对此复位的响应也不同。

3.2 J-Link 复位类型

• Normal（复位编号 0）：默认的复位策略，对于 i.MXRT 来说等同于 Core and peripherals 方式 Core（复位编号 1）：借助 Cortex-M 内核模块 SCB 中的 AIRCR 寄存器的 VECTRESET 位功能来复位 CoreCore and peripherals（复位编号 8）：借助 Cortex-M 内核模块 SCB 中的 AIRCR 寄存器的 VECTRESET 位和 SYSRESETREQ 位来同时复位 Core 和 MCU 外设模块 Reset Pin（复位编号 2）：通过拉低 J-Link 的 RESET 引脚（一般也会接到 MCU reset 脚）来复位 MCU

剩下几种复位类型不适用 i.MXRT，暂不介绍。

3.3 DAPLink 复位类型

• Disabled (no reset)：顾名思义，没有 reset 动作 Software：直接将 CPU 的 PC 指针重置到应用程序入口函数，相当于软复位 Hardware：通过翻转 DAPLink 的 nSRST/nRESET 引脚（一般也会接到 MCU reset 脚）来复位 MCUCore：借助 Cortex-M 内核模块 SCB 中的 AIRCR 寄存器的 VECTRESET 位功能来复位 CoreSystem：借助 Cortex-M 内核模块 SCB 中的 AIRCR 寄存器的 VECTRESET 位和 SYSRESETREQ 位来同时复位 Core 和 MCU 外设模块

剩下几种复位类型在 i.MXRT 上意义不大，暂不介绍。

四、复位类型对在线调试的影响

复位类型对在线调试的影响分两种：一、是否影响应用程序正常调试；二、是否影响应用程序正常运行。对于第二点，因为应用程序的设计差异，无法确定复位类型的不同导致的未复位模块对其产生何种影响，因此我们暂不讨论这点，我们主要看第一点。

设置不同的复位类型是否影响应用程序正常调试（能否停在程序入口函数，能否进行单步）？痞子衡在 MIMXRT1060-EVK 上实测了 SDK 里的 led_blinky 例程，选取了 debug（在 SRAM）和 flexspi_nor_debug（在 Flash）两个 build 做了很多组测试，结果如下：

从上表的测试结果，我们可以得到如下结论：

• 结论 1：在 SRAM 调试，完全不受复位类型和芯片启动模式影响（仅有掉电破坏 SRAM 里内容才可能影响调试）结论 2：在 Flash 调试，要想正常调试，要么不复位片上外设（保留 Flashloader 对 FlexSPI 等模块的初始化），要么启动模式设成 Flash Boot（让 BootROM 完成 FlexSPI 等模块的初始化），因为 Clock/GPIO/FlexSPI 的初始化必须保留，CPU 才能正常获得 Flash 里指令

至此，IAR 在线调试时设不同复位类型可能会导致 i.MXRT 下调试现象不一致现象痞子衡便介绍完毕了，掌声在哪里~~~