痞子衡嵌入式：IAR在线调试时设不同复位类型可能会导致i.MXRT下调试现象不一致(J-Link/DAPLink)

　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家分享的是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位功能来复位Core

Core 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脚）来复位MCU

Core：借助Cortex-M内核模块SCB中的AIRCR寄存器的VECTRESET位功能来复位Core

System：借助Cortex-M内核模块SCB中的AIRCR寄存器的VECTRESET位和SYSRESETREQ位来同时复位Core和MCU外设模块

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

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

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

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

例程Build	仿真器	复位类型	BootMode	调试现象
debug	J-Link DAPLink	所有的	2'b01 - SDP 2'b10 - Flash Boot	正常下载与调试
flexspi_nor_debug	J-Link	- Core	2'b01 - SDP 2'b10 - Flash Boot	正常下载与调试
flexspi_nor_debug	J-Link	- Normal - Core and peripherals - Reset Pin	2'b01 - SDP	正常下载，0x60000000处校验失败，无法调试
flexspi_nor_debug	J-Link	- Reset Pin	2'b10 - Flash Boot	正常下载与调试
flexspi_nor_debug	J-Link	- Normal - Core and peripherals	2'b10 - Flash Boot	正常下载，0x60000000处校验警告，但能正常调试
flexspi_nor_debug	DAPLink	- Disabled (no reset) - Software - Core	2'b01 - SDP 2'b10 - Flash Boot	正常下载与调试
flexspi_nor_debug	DAPLink	- Hardware - System	2'b01 - SDP	正常下载，0x60000000处校验失败，无法调试
flexspi_nor_debug	DAPLink	- Hardware	2'b10 - Flash Boot	正常下载与调试
flexspi_nor_debug	DAPLink	- System	2'b10 - Flash Boot	正常下载，0x60000000处校验警告，但能正常调试

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

结论1：在SRAM调试，完全不受复位类型和芯片启动模式影响（仅有掉电破坏SRAM里内容才可能影响调试）

结论2：在Flash调试，要想正常调试，要么不复位片上外设（保留Flashloader对FlexSPI等模块的初始化），要么启动模式设成Flash Boot（让BootROM完成FlexSPI等模块的初始化），因为Clock/GPIO/FlexSPI的初始化必须保留，CPU才能正常获得Flash里指令

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