本帖最后由 小恩GG 于 2020-4-2 15:39 编辑
MCUXPresso RT10xx SDRAM debug断点工作问题解决
一,文档说明
在实际的RT结合SDRAM以及MCUXPresso运行实例中,有些用户需要在MCUXpresso IDE 的平台上SDRAM中debug 代码,最近有个客户在使用的时候,有客户反映在debug的时候,断点不能正常工作。具体复现问题情况如下:
1. 硬件使用MIMXRT1050-EVKB
2. 代码使用SDK里面的iled_blinky
3. 在MCUXpressoIDE中导入RT1050的iled_blinky工程
4. 配置工程启动从SDRAM启动
在宏定义里面添加SKIP_SYSCLK_INIT SDRAM的仿真,把附件中的RT1050_SDRAM_Init.scp拷贝到IDE的安装路径:
C:\nxp\MCUXpressoIDE_11.1.0_3209\ide\binaries\Scripts
然后,MCUXpresso->run->Debug Configurations, 在connect script中添加SDRAM debug的脚本:
C:\nxp\MCUXpressoIDE_11.1.0_3209\ide\binaries\Scripts\RT1050_SDRAM_Init.scp
然后进入debug模式,打上几个断点,可以看到仿真进入的地址也是0X80000XXX开始的地址,确实是SDRAM所在区域,仿真发现,第一个断点可以进入,
但是再运行起来,就算第一个断点去掉,代码还是停在第一个断点,单步也会失败。
那么遇到这种问题,该如何解决呢?
二,解决方案
通过和MCUXpressoIDE部门的专家沟通,导致这个问题的原因还是data cache的情况, RT10XX为SDRAM使用写回WB cache操作, 或者说SDK为SDRAM配置了cache模式:
/* Region 7 setting: Memory with Normal type,not shareable, outer/inner write back */
MPU->RBAR= ARM_MPU_RBAR(7, 0x80000000U);
MPU->RASR= ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_32MB);
问题的原因是,debug环境不知道memory活动里面有cache包含进来,然后debug从被cache的SDRAM仿真会有一系列的问题。问题之一就是RAM中的断点通常是通过使用BKPT指令替换断点位置的指令来实现的, 断点后,必须首先将原始指令报错到替换的主机上。对代码的这种修改是数据方面的操作,因此你会得到内核所看到的内存以及主机端调试领域认为存在的内存的一致性问题。
那么如何解决这个问题呢?
在NXP的官方论坛有一篇文章:
Debugperformance and the Data Cache章节,可以通过在debugger option中添加additional options :
--no-packed--cachelib libm7_cache.so
然后再仿真情况如下:
可以发现,多断点已经可以工作,单步也可以工作,能够解决问题。 |