• 状态
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 160 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] TMS570LS3137：取决于目标地址的分支指令成功

admin
Guru**** 2553260 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1286541/tms570ls3137-branch-instruction-success-dependent-on-target-address

器件型号：TMS570LS3137

您好！

我发现一个与 https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/962007/ccs-tms570lc4357-branch-to-_c_int00-from-reset-vector-is-not-working/3558660?tisearch=e2e-sitesearch&keymatch=branch%25252520%25252526%25252526%25252520alignment#3558660类似的问题

我在汇编中编写了一个异常处理程序、它分支到异常之后。  

在上下文中、数据中止作为启动自检例程的一部分生成。 在这些数据中止期间、 会发生以下事件之一、具体取决于_exception_handler_的位置：

  1. 成功分支到_exception_handle_。
  2.  PC 不会分支到_exception_handler_、而是递增到下一条指令(phantomEntry)。 此时、调试工作变得不可预测(nRST 会导致重置为随机位置-不是0x0、"恢复"操作会导致"步进"操作等)

请注意在故障情况下捕获的以下屏幕截图。

A)抛出数据中止。

 

b) 在"汇编步骤进入"操作后、PC 递增到下一条指令、而不分支到_except_handle_。

记录的成功/失败案例如下所示：

异常处理程序_地址 测试结果
0x2FB98 失败
0x2FB9C 失败
0x2FBA0 失败
0x2FC10 失败
0x2FC0C 失败
0x2FC08 失败
0x2FC18 通过
0x2FC1C 通过
0x2FC20 通过
0x2FC28 通过
0x2FC2C 通过
0x2FC30 通过
0x2FC88 通过
0x30B08 通过

此外、我已经 通过内存浏览器以及输出.bin 文件在失败和成功情况下验证分支指令是正确的。

非常感谢您提供任何输入。

谢谢。

格雷森

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

    尊敬的  Grayson：

    已开始处理您的主题、并将尽快提供更新。

    --
    谢谢。此致、
    Jagadish。

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

    尊敬的 Grayson：

    您能否进行一次测试、并告诉我状态、无论问题是否仍然存在。

    1.请删除项目中的调试文件夹:

    2.现在选择"Clean"构建选项

    并选择相应的工程进行清理构建、

    然后单击"clean"

    3.现在再做一次测试,让我知道结果。

    --
    谢谢。此致、
    Jagadish。

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

    Jagadish、您好！

    遗憾的是、这无法解决问题。

    我可以通过在可正常工作的闪存区域中包含_exception_handler_来暂时解决该问题。 但是、我们希望在项目完成之前做到这种根本原因。

    谢谢。

    格雷森

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

    尊敬的 Grayson：

    在您的代码中、  幻象、未定义、SVC、数据中止、预取中止的异常是否共享中断处理程序(_exception_handle_)？处理程序如何确定异常的来源？

    您可以尝试其他方式来将代码分支到正确的处理程序地址吗？

    LDR PC、reset_addr
    LDR PC、undefined_addr  
    LDR PC、Svc_addr  
    LDR PC、prefetch_abort_addr
    LDR PC、DATA_ABORT_addr
    LDR PC、幻象地址
    LDR PC，[PC,#-0x1b0]
    LDR PC，[PC,#-0x1b0]

    reset_addr：.long _c_int00
    undefined_addr：.long _exception_handler_  
    SVC_addr：.long _exception_handler_  
    prefetch_abort_addr：.long _exception_handler_  
    DATA_ABORT_addr：.long _exception_handler_  
    Phantom_addr：.long _exception_handler_  

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

    您好、QJ：

    处理程序如何确定异常的来源？

    我们读取 CPSR 寄存器以确定模式。 数据中止和预取中止的处理方式相同。

    您可以尝试其他方式来将代码分支到正确的处理程序地址吗？

    这似乎起作用！ 我可以在处理数据中止时逐步执行预期的 LDR 指令。 已使用地址0x2FB98和0x2FB9C 进行验证。

    下一个问题是为什么分支指令在加载指令工作时失败？ 您是否能够在本地重现此示例？

    谢谢、

    格雷森

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

    尊敬的  Grayson：

    分支指令包含一个带符号的二进制补码24位偏移。 分支地址为 PC 加上已移位的偏移量：

    在您的示例中、  

    0xEA000BEFC：分支地址为0xBEFC<<2 + 0x10+0x8 (PC 是当前指令前2个字)

    它是0x2FC08

    如果将处理程序放在其他位置、则必须更改所有相关 BL 指令(在0x08、0x10、0x14等处)的偏移量

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

    您好、QJ：

    感谢您的分析。 但是、我不确定根本原因是什么。

    如果分支指令目标为 0x2FC08、这不是上述测试的预期行为？ 在异常处理程序位置被移动的其他测试中、不应该在编译期间动态计算 b _exception_handle_指令生成的分支目标？

    谢谢。

    格雷森

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

    尊敬的 Grayson：

    QJ 正在度假到1月2日,请预计他的答复会有一些延迟。

    --
    谢谢。此致、
    Jagadish。