痞子衡嵌入式：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调试执行的影响。ide
1、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"一表。测试
2、两种调试分类(在Flash/在RAM)
在i.MXRT上根据应用程序代码(read only段)连接位置所属的存储器性质，在线调试主要分为两类：在外部Flash调试和在内部SRAM调试（在外部SDRAM/HyperRAM调试暂不在考虑范畴）。flex
由于外部Flash数据不能像内部SRAM上那样直接写入，须要调用额外的Flash下载算法才能写入，所以C-SPY处理在Flash调试和在SRAM调试的流程有一些区别。ui
首先来看C-SPY处理在内部SRAM调试的流程，C-SPY调试器启动后设置好合适的JTAG速度后便开始挂起目标板上的CPU（即MCU中Cortex-M内核），而后直接经过JTAG口和AHB总线往目标板上的MCU内部SRAM里写入应用程序镜像数据，写完再进行可选的数据校验和用户Reset/Setup后即可以操控CPU开始执行SRAM里的应用程序。.net
再来看C-SPY处理在外部Flash调试的流程，C-SPY调试器挂起CPU后先是往MCU内部SRAM里加载了一个Flashloader程序（即Flash下载算法），而后让CPU执行Flashloader来完成应用程序镜像数据的Flash烧写，烧写完成以后再次挂起CPU，进行可选的数据校验和用户Reset/Setup后便操控CPU开始执行Flash里的应用程序。debug
你须要特别留意一下这两张流程图里可选的CPU reset动做，咱们看到在SRAM调试流程中仅在写入应用程序镜像前有一次CPU reset，而在Flash调试流程中烧写应用程序镜像先后均有一次CPU reset动做，为何在Flash调试须要多一次CPU reset？这是由于Flashloader程序会初始化MCU外设模块（好比Clock，GPIO，FlexSPI等），这些初始化过的MCU外设模块若是不复位到初始状态可能会对后面应用程序的执行产生必定影响。
3、复位类型全解析
好了，如今咱们进入正题，开始介绍复位类型，上一节讲的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上意义不大，暂不介绍。
4、复位类型对在线调试的影响
复位类型对在线调试的影响分两种：1、是否影响应用程序正常调试；2、是否影响应用程序正常运行。对于第二点，由于应用程序的设计差别，没法肯定复位类型的不一样致使的未复位片上外设对其产生何种影响，所以咱们暂不讨论这点，咱们主要看第一点。
设置不一样的复位类型是否影响应用程序正常调试（可否停在程序入口函数，可否进行单步）？痞子衡在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下调试现象不一致现象痞子衡便介绍完毕了，掌声在哪里~~~
欢迎订阅
文章会同时发布到个人 博客园主页、CSDN主页、知乎主页、微信公众号 平台上。
微信搜索"痞子衡嵌入式"或者扫描下面二维码，就能够在手机上第一时间看了哦。