痞子衡嵌入式:MCUXpresso IDE下在线调试时使用不同复位策略的现象总结

时间:2021-09-28 02:29:39

  大家好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给大家分享的是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下复位策略,最后再给大家解谜。

痞子衡嵌入式: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命令里找到详细解释。

痞子衡嵌入式:MCUXpresso IDE下在线调试时使用不同复位策略的现象总结

  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日志,在日志中查看具体顺序。

痞子衡嵌入式:MCUXpresso IDE下在线调试时使用不同复位策略的现象总结

  在实际使用中,痞子衡推荐不使能红框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里为这个默认调试器实现了友好的复位类型选项。

痞子衡嵌入式:MCUXpresso 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),否则没法正常调试。

痞子衡嵌入式:MCUXpresso IDE下在线调试时使用不同复位策略的现象总结

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

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

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

例程Build 仿真器 复位类型 BootMode 调试现象
flexspi_nor_debug J-Link monitor reset 1 2'b01 - SDP

2'b10 - Flash Boot
正常下载与调试
flexspi_nor_debug J-Link monitor reset 0/2 2'b01 - SDP 正常下载,无法调试
flexspi_nor_debug J-Link monitor reset 0/2 2'b10 - Flash Boot 正常下载与调试
flexspi_nor_debug LinkServer - SOFT 2'b01 - SDP

2'b10 - Flash Boot
正常下载与调试,注意程序不能含XIP头
flexspi_nor_debug LinkServer - 除SOFT外其余四种 2'b01 - SDP 正常下载,无法调试
flexspi_nor_debug LinkServer - 除SOFT外其余四种 2'b10 - Flash Boot 正常下载与调试

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

  • 结论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不会被启动,因此无法硬复位后进调试。

痞子衡嵌入式:MCUXpresso IDE下在线调试时使用不同复位策略的现象总结

  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下在线调试时使用不同复位策略的现象总结痞子衡便介绍完毕了,掌声在哪里~~~

欢迎订阅

文章会同时发布到我的 博客园主页CSDN主页知乎主页微信公众号 平台上。

微信搜索"痞子衡嵌入式"或者扫描下面二维码,就可以在手机上第一时间看了哦。

痞子衡嵌入式:MCUXpresso IDE下在线调试时使用不同复位策略的现象总结