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

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家分享的是MCUXpresso IDE下在线调试时使用不同复位策略的现象总结。

本篇实际上是《IAR在线调试时设不同复位类型可能会导致i.MXRT下调试现象不一致》的同系列篇，计划中痞子衡是要把几大经典IDE（IAR EWARM、Keil MDK、MCUXpresso IDE）下的复位策略都写一遍，但一直没抽出时间。今天痞子衡恰好帮助一位印度同事解决了在客户板子上使用MCUXpresso在线调试的问题，因此顺便认真研究了下MCUXpresso IDE下复位策略，特地分享给大家。

在读本文前，最好把痞子衡先前写过的一篇 《MCUXpresso IDE下使用J-Link下载算法在Flash调试注意事项》 浏览一下，本文要探讨的问题比先前那篇文章要更深入。

• Note: 痞子衡测试的MCUXpresso IDE版本是v11.3.0_5222。

一、在客户板卡上遇到的调试问题

先来回顾下客户遇到的调试问题。据印度同事介绍，客户自己设计的i.MXRT1052板卡，使用的Flash是Cypress生产的S25FL128LAGMFI01，客户寄了一块样卡给我同事，我同事在客户板卡上随便找了个SDK里的hello world工程（MCUXpresso IDE）去在线调试，调试器是恩智浦的LPC-Link2。

i.MXRT1050 SDK工程里默认选择的下载算法是适用官方EVK上默认Hyper Flash的，并不适用客户这块板卡上的QSPI Flash，因此印度同事为客户制作了一个LinkServer Flash Driver（MCUX下载算法），使用这个新制作的下载算法可以去下载（至少从MCUX的下载日志里可以看到Flash Write Done），但是断点没能停在main函数，因此无法单步调试，而且在IDE里检查0x60000000处空间，看到的是如下无效数据，就像是程序根本没有下载进去，这到底是怎么回事？痞子衡接下来就先为大家分析MCUXpresso IDE下复位策略，最后再给大家解谜。

关于LinkServer Flash Driver的制作可参考痞子衡之前写过的 《串行NOR Flash下载算法(MCUXpresso IDE篇)》，但其实这个客户选择的S25FL128LAGMFI01就是块普通的符合JEDEC SFDP标准的QSPI NOR，在MCUXpresso IDE安装目录下的MIMXRT1050_SFDP_QSPI.cfx算法是可以直接使用的（路径是 \MCUXpressoIDE_11.3.0_5222\ide\binaries\Flash）。

二、MCUXpresso IDE调试机制与调试分类

关于MCUXpresso IDE下的调试机制原理在 \MCUXpressoIDE_11.3.0_5222\MCUXpresso_IDE_User_Guide.pdf 手册里并没有找到设计性的介绍，虽然手册里一共有如下四个章节涉及到了下载调试，但更多是介绍如何在IDE里使用下载调试功能。

10. Debug Solutions Overview
11. Debugging a Project
14. The GUI Flash Tool
15. LinkServer Flash Support

不过调试机制在各IDE上大同小异，设计理念都是一致的，这部分建议参考《IAR在线调试时设不同复位类型可能会导致i.MXRT下调试现象不一致》里的一、二章节。

三、复位类型全解析

好了，现在我们进入正题，开始介绍MCUXpresso IDE下复位类型。我们知道不同硬件仿真器下复位功能有差异，痞子衡主要介绍i.MXRT上两种最常用的仿真器：J-Link和DAPLink。此外不管是哪种仿真器，其都借助了Cortex-M7内核功能，内核在SCB模块的AIRCR寄存器中集成了复位的支持，详见 《IAR在线调试时设不同复位类型可能会导致i.MXRT下调试现象不一致》 的 3.1 Cortex-M7复位功能 小节。

3.1 J-Link复位类型

MCUXpresso IDE下设置J-Link复位类型一共有如下图所示三处，其本质上都是借助Jlink底层命令，具体可在 \SEGGER\JLink_V686f\Doc\Manuals\UM08001_JLink.pdf 文档中的Supported remote (monitor) commands 小节里的reset命令以及 List of available commands 小节里的SetResetType命令里找到详细解释。

UM08001_JLink.pdf 文档中的 7.10.2 Strategies for Cortex-M devices 小节一共列出了如下三种复位类型：

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

上图复位类型设置框中的三处设置，虽然都能使能复位操作，但是阶段不同，其中红框2处设置是的下载前操作，红框3处设置是下载后的操作，红框1处设置是执行前的操作。如果你对这个顺序不了解，可以做个试验，比如我们在红框3处设置复位类型1，在红框1处设置复位类型2，进入调试后在日志窗口找到JLinkServer日志，在日志中查看具体顺序。

在实际使用中，痞子衡推荐不使能红框1中的"Reset before running"选项，并且仅在红框3中设置复位类型，经测试这种方式与其他IDE下的调试体验最一致。但还是有如下两点注意事项：

• Note1: 复位命令后，必须增加一个monitor reg pc设置，否则无法正常调试。
• Note2: 复位类型是0的情况下，如果此时BootROM没能正常启动App（即应该不能正常调试），但在IDE界面里有时候还是会停在main函数，这其实是假象（应该跟cache有关），并不能正常调试，点击suspend按钮就能看到跑飞。

3.2 LinkServer复位类型

LinkServer即对应DAPLink调试器，是MCUXpresso IDE默认的调试器类型，IDE里为这个默认调试器实现了友好的复位类型选项。

上图复位类型设置红框1中的“Reset handling”一共提供了五种复位选择。这五种复位除了SOFT外，其余都不会主动设PC指针，默认全靠breakpoint去触发调试。

• Default：等同于于SYSRESETREQ方式
• SYSRESETREQ：借助Cortex-M内核模块SCB中的AIRCR寄存器的SYSRESETREQ位来同时复位MCU外设模块
• VECTRESET：借助Cortex-M内核模块SCB中的AIRCR寄存器的VECTRESET位功能来复位Core
• SOFT：直接将CPU的PC指针重置到应用程序入口函数，相当于软复位
• 空：等同于SYSRESETREQ方式

同上节JLink复位类型一样，LinkServer下也提供了额外的Commands设置（红框2/3），具体命令写法需查看 MCUXpresso_IDE_User_Guide.pdf 手册，本文就不详细介绍了。

关于Reset handling选择SOFT方式的结果，有一点需要特别指出，我们在如下对应日志里可以看到，下载完成后调用了soft reset并且从0x60000000处拿了SP和PC，即MCUXpresso IDE认为下载首地址就是程序中断向量表起始地址，这个假定在i.MXRT的XIP工程上其实是不成立的，我们知道正确的中断向量表起始地址应该是0x60002000。如想让MCUXpresso IDE拿到正确的SP/PC，应该在XIP工程预编译选项里把XIP_BOOT_HEADER_ENABLE设成0（也可以研究下在红框3中增加LinkServer命令去设置PC），否则没法正常调试。

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

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

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

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

• 结论1：在Flash调试，要想正常调试，要么不复位片上外设（保留Flashloader对FlexSPI等模块的初始化），要么启动模式设成Flash Boot（让BootROM完成FlexSPI等模块的初始化），因为Clock/GPIO/FlexSPI的初始化必须保留，CPU才能正常获得Flash里指令。
• 结论2：JLink复位下，MCUXpresso IDE调试体验与其他IDE是一致的。
• 结论3：LinkServer复位下，MCUXpresso IDE下VECTRESET方式复位达不到其他IDE下同等方式的效果，因为初始PC无法得到。

五、客户板卡上调试问题的原因

最后回到客户板上的问题，痞子衡的印度同事其实是非常有经验的，板卡启动模式设置，Flash下载算法，工程里的FDCB头全部都是正确的，但是经查明板卡i.MXRT1052芯片的eFuse中BOOT_CFG2[3]位被烧写成了1，即芯片进入了inifnite loop模式，PC永远停在BootROM里，客户App不会被启动，因此无法硬复位后进调试。

BootROM中系统初始化函数里对BOOT_CFG2[3]位的处理代码：

volatile uint32_t infinite_loop;

void SystemInit (void)
{
#if ((__FPU_PRESENT == 1) && (__FPU_USED == 1))
  SCB->CPACR |= ((3UL << 10*2) | (3UL << 11*2));    /* set CP10, CP11 Full Access */
#endif /* ((__FPU_PRESENT == 1) && (__FPU_USED == 1)) */

    TRACE("BootROM: SystemInit\n");

    rtwdog_disable();

    /* Below codes is used for issue troubleshooting on real chip */
    if ((ROM_OCOTP_INFINITE_LOOP_VALUE() == 1) && (ROM_OCOTP_DIR_BT_DIS_VALUE() == 0))
    {
        infinite_loop = 1;
        while(infinite_loop)
        {
        }
    }

    // 代码省略
}

至此，MCUXpresso IDE下在线调试时使用不同复位策略的现象总结痞子衡便介绍完毕了，掌声在哪里~~~

1.Arm推出v9架构，据称可以授权华为！

2.华为鸿蒙究竟是什么？我们和鸿蒙开发者聊了聊

3.大佬为何可以把单片机描述得如此形象生动？

4.职业劝退师的苦笑：嵌入式老干饭人们，饭碗保住了

5.美国半导体产业协会发布《在不确定的时代加强全球半导体供应链》报告

6.手把手教你嵌入式C语言优化技巧

免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。