请选择 进入手机版 | 继续访问电脑版
查看: 855|回复: 0

[分享] [痞子衡]不同复位类型设置对MCUXpresso IDE在线调试有何影响?

[复制链接]
  • TA的每日心情
    开心
    3 天前
  • 签到天数: 266 天

    [LV.8]以坛为家I

    3296

    主题

    6541

    帖子

    0

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    31904
    最后登录
    2024-3-28
    发表于 2021-12-29 13:11:45 | 显示全部楼层 |阅读模式
    不同复位类型设置对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下复位策略,最后再给大家解谜。
    13.png
    关于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里使用下载调试功能。
    1. 10. Debug Solutions Overview
    2. 11. Debugging a Project
    3. 14. The GUI Flash Tool
    4. 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命令里找到详细解释。
    14.png
    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日志,在日志中查看具体顺序。
    15.png
    在实际使用中,痞子衡推荐不使能红框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里为这个默认调试器实现了友好的复位类型选项。
    16.png
    上图复位类型设置红框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),否则没法正常调试。
    17.png
    四、复位类型对在线调试的影响
    复位类型对在线调试的影响分两种:一、是否影响应用程序正常调试;二、是否影响应用程序正常运行。对于第二点,因为应用程序的设计差异,无法确定复位类型的不同导致的未复位模块对其产生何种影响,因此我们暂不讨论这点,我们主要看第一点。


    设置不同的复位类型是否影响应用程序正常调试(能否停在程序入口函数,能否进行单步)?痞子衡在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不会被启动,因此无法硬复位后进调试。
    18.png

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

    1. volatile uint32_t infinite_loop;

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

    7.     TRACE("BootROM: SystemInit\n");

    8.     rtwdog_disable();

    9.     /* Below codes is used for issue troubleshooting on real chip */
    10.     if ((ROM_OCOTP_INFINITE_LOOP_VALUE() == 1) && (ROM_OCOTP_DIR_BT_DIS_VALUE() == 0))
    11.     {
    12.         infinite_loop = 1;
    13.         while(infinite_loop)
    14.         {
    15.         }
    16.     }

    17.     // 代码省略
    18. }
    复制代码
    至此,MCUXpresso IDE下在线调试时使用不同复位策略的现象总结痞子衡便介绍完毕了,掌声在哪里~~~

    签到签到
    回复

    使用道具 举报

    您需要登录后才可以回帖 注册/登录

    本版积分规则

    关闭

    站长推荐上一条 /4 下一条

    Archiver|手机版|小黑屋|恩智浦技术社区

    GMT+8, 2024-3-29 06:29 , Processed in 0.122476 second(s), 21 queries , MemCache On.

    Powered by Discuz! X3.4

    Copyright © 2001-2021, Tencent Cloud.

    快速回复 返回顶部 返回列表