This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CCS/CC2564CMSP432BTBLESW:调试器中的硬故障和奇怪的单步行为、代码位于 SRAM 中

Guru**** 2964200 points

Other Parts Discussed in Thread: CC2564C

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/896018/ccs-cc2564cmsp432btblesw-hard-fault-and-weird-single-stepping-behavior-in-debugger-with-code-in-sram

器件型号:CC2564CMSP432BTBLESW
主题中讨论的其他器件:CC2564C、 MSP432P401R

工具/软件:Code Composer Studio

我使用与包含 CC2564C 芯片和音频编解码器的 PCB 堆叠的 MSP432 Launchpad 2.0。 软件库是 Samples 目录中的 A3DPDemo_SNK。 升级到 Bluetopia 4.2.1.1后、我可以连接到设备、一切正常。

但是、在添加其他功能后、程序不再适合主存储器。 在研究 了 TI 链接器命令文件入门之后 、我将两个目标文件(A3DPDemo_SNk.obj 和 btvs.obj)移动到了 SRAM_CODE 存储器范围中。 只有这样、MCU 才会在 BT 堆栈初始化期间遇到硬故障。 按照 本帖子中给出的指令 、我设法在硬件故障发生之前检查了调用堆栈和函数:HCI_VS_InitializeAfterHCIReset。 因此、我在内部放置一个断点并重新启动以进行调试。 单步执行对 VS_Update_UART_Baud_rate (BluetoothStackID、SpecifiedBaudRate)的调用后、会发生硬故障。 那么、我进入了该函数。 (缩短的)代码如下所示:

if ((BluetoothStackID)&&(波特率)&&(波特率<= CONTROLLER_MAX_HCI_BAUD_RATE)
){
/*写入波特率。 */
。
RET_val = HCI_Send_Raw_Command (BluetoothStackID、OGF、OCF、sizeof (NonAlignedDWord_t)、(Byte_t *)&&波特率、 状态(&S)、长度(&L)、缓冲区、真);
if ((ret_val = MapSendRawResults (ret_val、状态、长度、缓冲区))==0)
{
...
RET_val = HCI_RECONFIG_Driver (BluetoothStackID、false 和(DriverReconfigureData));
}
}
否则
RET_val = BTPS_ERROR_INVALID_PARAMETER; 

调试器单步进入 if-子 句(正确)并在其末尾调用 HCI_RECONFIGURE _Driver() 到目前为止还不错,但后来开始了一些奇怪的事情:

调试器进入 else-部分并在那里继续执行! 任何进一步的单步执行(使用 F6)似乎只是遵循源文件中的每个函数/语句。 到达 return 语句后、它不会返回、但会继续从源代码文件执行下一个函数。 我不会得到这个-查看变量的值也会产生错误的结果。 这里发生什么事了?



  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    [引用 user5315609]Debugger 步骤进入 else-part 并在那里继续执行! 任何进一步的单步执行(使用 F6)似乎只是遵循源文件中的每个函数/语句。 到达 return 语句后、它不会返回、但会继续从源代码文件执行下一个函数。 我不会得到这个-查看变量的值也会产生错误的结果。 这里发生了什么?[/报价]

    很难说没有测试用例、但听起来像是 a)调试器引用的源文件与用于编译的源文件不同、或者 b)代码经过优化、这会影响调试可见性。

    您能否检查"Disassembly"视图并查看交错源代码行是否与汇编器指令匹配?

    谢谢

    Ki

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    这是一个真正的大问题:在切换到"Disassembly"视图后、我了解为什么会发生我所描述的情况:

    令人沮丧的是-我从原始 MSP432P401R 链接器命令文件开始、但放入 SRAM_CODE 存储器范围的每个代码都会评估为零! 以下是原始代码:

    内存
    {
    主程序 (Rx):origin = 0x00000000、length = 0x00040000
    信息 (Rx):origin = 0x00200000、length = 0x00004000
    SRAM_CODE (rwx):origin = 0x01000000、length = 0x00010000
    SRAM_DATA (RW):origin = 0x20000000,length = 0x00010000
    } 

    在我看来、在链接器命令文件中定义的地址0x01000000处没有 SRAM。

    在检查 SRAM_DATA 的内容后、我将存储器范围更改为:

    SRAM_CODE (rwx):origin = 0x20000000、length = 0x00005000
    SRAM_DATA (RW):origin = 0x20005000,length = 0x0000B000 

    现在一切都正常。 但这意味着什么-我的 LaunchPad 是否损坏? 该地址是否不应该有 SRAM?

    最后但同样重要的是:为什么在写入不存在的存储器时 CCS 不会警告我?

    感谢@Ki 给我指了正确的方向!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    查看数据表、我相信您不能将代码放置在0x20000000处。  它是 RW 但不是 X。  https://www.ti.com/lit/ds/symlink/msp432p401r.pdf

    代码区存储器映射0x0000_0000到0x1FFF_FFFF 的区域定义为代码区、可通过 Cortex-M4处理器的 ICODE 和 DCODE 总线以及系统 DMA 进行访问。 该区域映射了闪存、ROM 和内部 SRAM (允许从 SRAM 进行最佳单周期执行)。

    CCS 不会向您发出警告、因为存储器确实存在。   

    此致、

    John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我看到了您的观点、这就让我回到了原来的问题:我已经将代码放入了地址0x0100_0000的 SRAM 中(正如它应该是根据图所示的那样)。 6-2)、但随后调试器会将该位置的 SRAM 内容评估为零! 刚刚意识到我的屏幕截图在上面4月14日发布的帖子中缺失、因此下面是手动复制的反汇编视图:

    BD_ADDRToStr():
    01000000:0000 MOV R0、r0
    01000002:0000 MOV R0、R0
    01000004:0000 MOV R0、r0
    01000006:0000 MOV R0、r0
    01000008:0000 MOV R0、r0
    0100000a:0000 MOV R0、r0
    344 BTPS_sprintf ((char *) BoardStr、"0x%02x%02x%02x%02x%02x%02x"、Board_Address.BD_Addr5、Board_Address.BD_Addr4、Board_Address.BD_Addr3、 Board_Address.BD_ADDDR2、Board_Address.BD_ADDR1、Board_Address.BD_ADDR0);
    0100000c:0000 MOV R0、r0
    0100000e:0000 MOV R0、r0
    01000010:0000 MOV R0、r0
    01000012:0000 MOV R0、r0
    01000014:0000 MOV R0、r0
    01000016:0000 MOV R0、r0
    01000018:0000 MOV R0、r0
    0100001a:0000 MOV R0、r0
    0100001c:0000 MOV R0、r0
    0100001e:0000 MOV R0、r0
    01000020:0000 MOV R0、r0
    01000022:0000 MOV R0、r0
    01000024:0000 MOV R0、r0
    01000026:0000 MOV r0、r0
    345} 

    将链接器命令文件中的 SRAM_CODE 地址更改为0x2000_0000后、如下所示:

    343 {
    BD_ADDRToStr():
    200000e4:B403 按 {r0、r1}
    200000e6:B580 按 {r7、r14}
    200000e8:AF02 添加 R7、R13、#8
    200000ea:F1AD0D18 子项 w R13、R13、#0x18
    200000ee:9204 结构 R2、[R13、#0x10]
    344 BTPS_sprintf ((char *) BoardStr、"0x%02x%02x%02x%02x%02x%02x"、Board_Address.BD_Addr5、Board_Address.BD_Addr4、Board_Address.BD_Addr3、 Board_Address.BD_ADDDR2、Board_Address.BD_ADDR1、Board_Address.BD_ADDR0);
    200000f0:78F8 ldrb R0、[r7、#3]
    200000f2:9000 结构 R0、[R13]
    200000f4:78B8 ldrb R0、[r7、#2]
    200000f6:9001 结构 R0、[R13、#4]
    200000f8:7878 ldrb R0、[r7、#1]
    200000fa:9002 结构 R0、[R13、#8]
    200000fc:7838 ldrb R0、[r7]
    200000fe:9003 结构 R0、[R13、#0xc]
    20000100:793B ldrb R3、[r7、#4]
    20000102:797A ldrb R2、[r7、#5]
    20000104:9804 LDR R0、[R13、#0x10]
    20000106:A194 ADR R1、#0x250
    20000108:F002F978 BL $Tramp$TT$L$PI$BTPS_sprintf
    345}
    

    更重要的是:程序工作正常、而不是像在原始链接器命令文件中那样导致硬故障。 那么、将地址0x0100_0000处的原始存储器区域用于 SRAM_CODE 会出现什么问题? CCS 工程中是否存在任何其他参数(我不知道)、这些参数可以:

    a)使我的配置即使在我将代码放入不可执行的地址空间时也能正常工作

    b)使原始存储器映射失败、如反汇编视图中所示?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="user5315609"]

    更重要的是:程序工作正常、而不是像在原始链接器命令文件中那样导致硬故障。 那么、将地址0x0100_0000处的原始存储器区域用于 SRAM_CODE 会出现什么问题? CCS 工程中是否存在任何其他参数(我不知道)、这些参数可以:

    a)使我的配置即使在我将代码放入不可执行的地址空间时也能正常工作

    b)使原始存储器映射失败、如反汇编视图中所示?

    [/报价]

    我需要与一些器件专家交流。 他们可以提供更多见解。

    谢谢

    Ki