不同复位类型设置对MCUXpresso IDE在线调试有何影响?
痞子衡嵌入式 2022-09-19

今天给大家分享的是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 Overview11. Debugging a Project14. The GUI Flash Tool15. 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做了很多组测试,结果如下:

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

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


本文源自微信公众号:痞子衡嵌入式,不代表用户或本站观点,如有侵权,请联系nick.zong@aspencore.com 删除!

声明: 本文转载自其它媒体或授权刊载,目的在于信息传递,并不代表本站赞同其观点和对其真实性负责,如有新闻稿件和图片作品的内容、版权以及其它问题的,请联系我们及时删除。(联系我们,邮箱:evan.li@aspencore.com )
0
评论
  • 报名中:IIC Shenzhen - 2022国际集成电路展览会暨研讨会


  • 相关技术文库
  • 单片机
  • 嵌入式
  • MCU
  • STM
  • 以32位微处理器为控制核心的超级电容器组管理系统

    在传统的能量供应系统中,电池作为主要的储能单元被广泛使用。随着科学技术的发展和保护环境的需求,超级电容器因其容量大、寿命长、放电速度快、工作温度范围宽、可以串并

    09-30
  • 多节动力电池检测系统的单片机控制模块

    针对动力电池工作参数的监测,保护其安全性和使用寿命的问题,提出基于电池管理芯片 LTC6803 设计一套电池管理系统,利用 LTC6803 和 STC12C54

    09-30
  • CFS任务的负载均衡

    负载均衡的系列文章共分为三篇,第一篇为框架篇,描述负载均衡的相关原理、场景和框架。本篇作为该系列文章第二篇,主要通过对任务放置场景(task placement)的均衡分布进行分析,以便加深读者对内核调度器实现任务均衡分布的理解。 本文基于linux-5.4.24分

    09-29
  • Multi-queue 架构分析

    Linux上传统的块设备层(Block Layer)和IO调度器(如cfq)主要是针对HDD(hard disk drivers)设计的。我们知道,HDD设备的随机IO性能很差,吞吐量大约是几百IOPS(IOs per second),延迟在毫秒级,所以当时IO性能的瓶颈在硬件,而不是内核。但是,随着高速

    09-29
  • ARMv8 异常处理简介

    内核稳定性问题复杂多样,最常见的莫过于“kernel panic”,意为“内核恐慌,不知所措”。这种情况下系统自然无法正常运转,只能自我结束生命,留下死亡信息。诸如: “Unable to handle kernel XXX at virtual address XXX” “undefined instruction XXX”

    09-29
  • 新型 IO 调度器 BFQ 简介

    Linux io调度器有很多种,大多数调度器都经受住了各种市场环境的长时间验证,稳定性、性能得到各种用户的认可,但新的调度器依然展露头角,在4.12内核中出现了一个新的bfq调度器,这个调度器将取代曾经的辉煌的cfq调度器。社区对待大的改动都是很谨慎的,为什

    09-29
  • CFS任务的负载均衡(框架篇)

    我们描述负载均衡的系列文章一共三篇,第一篇是框架部分,即本文,主要描述了负载均衡相关的原理、场景和框架。后面的两篇是对均衡代码的情景分析,通过对load balance、task placement和active upmigration几个典型的负载均衡来呈现其实现细节,稍后发布,敬

    09-29
  • linux IO Block layer 解析

    早期的 Block 框架是单队列(single-queue)架构,适用于“硬件单队列”的存储设备(比如机械磁盘),随着存储器件技术的发展,支持“硬件多队列”的存储器件越来越常见(比如 NVMe SSD),传统的单队列架构也因此被改成了多队列(multi-queue)架构。早在 3.

    09-29
  • eMMC简介

    1 eMMC是什么 eMMC是embedded MultiMediaCard的简称,即嵌入式多媒体卡, 是一种闪存卡的标准,它定义了基于嵌入式多媒体卡的存储系统的物理架构和访问接口及协议,具体由电子设备工程联合委员会JEDEC订立和发布。 它是对 MMC的一个拓展,具有体积小,功耗低,

    09-29
  • 低纹波、高精度电流源设计

    低纹波、高精度电流源是一种重要的仪器设备;广泛应用于电光源、电化学、通信、测量技术、电子仪器等领域。目前,市场上的电流源不具备连续可调功能;并且输出电流范围小、

    09-29
  • Linux 电信基站系统解决方案

      自从1991年Linux第一次面世以来,任何人也不会想到这个不起眼的操作系统现在会应用得如此广泛。无论是从嵌入式领域的智能手机到大型计算服务器都可以找到它的

    09-28
  • 单片机振荡电路中如何选择晶体?

    1.单片机晶振的原理晶振一般采用三端式(考毕兹) 交流等效振荡电路;实际的晶振交流等效电路中,其中Cv是用来调节振荡频率,一般用变容二极管加上不同的反偏电压来实

    09-28
下载排行榜
更多
广告