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.

[参考译文] AM5K2E02:调试内核停止

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1052948/am5k2e02-debugging-a-core-stall

器件型号:AM5K2E02

大家好、

我们遇到了自定义电路板内核停止/挂起/锁定问题。

虽然我们在单核配置下运行、但我们认为此问题与勘误表#798870无关、因为我们:

  • 在 L2ACTLR 中设置危险检测超时位
  • 根据权变措施(停止后继续运行)定期运行 DMA
  • 即使禁用 L2缓存(SCTLR 清除中的 C 位)也已观察到停止  
  • 可以在几分钟内定期体验这种失速

我们已经确认、我们正在访问的外设(DDR3、PCIe)仍然通过 DAP 进行响应。

我们目前使用 Lauterbach 探针;最近我们遇到了类似的失速问题、通过更改用于连接探针的命令来缓解这一问题。 对于我们的探头、使用"System.up"进行初始连接会导致我们的应用程序版本每次在同一个部分停止运行(即我们使用"system.up"进行连接、加载引导加载程序、运行引导加载程序、加载映像、运行映像、 然后、它每次都在大致相同的区域内失速)。 为了解决此问题、我们发现使用"system.attach"后跟"break.direct"或在未连接调试器的情况下(物理或其他方式)运行应用程序不会导致停止。

这两个命令都初始化了调试/JTAG 端口;区别在于连接不执行复位、也不会停止处理器状态的更改。

遗憾的是、实际断开调试器仍会导致我们当前的失速情况。 我们不知道这是单独的失速问题、还是调试器加剧了相同的失速问题。

我们希望能够询问内核并检查其处于何种状态、但由于停止、通过调试器对内核的所有访问和控制都将停止。 例如、尝试停止执行会导致调试器抛出"仿真运行"错误;尝试访问内核寄存器会导致故障和"总线错误"

我们是否可以采取任何步骤来尝试解决正在发生的情况以及原因? 我们是否可以/应该查询任何寄存器来查看 SoC 的内部状态?

非常感谢

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

    Daniel、您好!

    您是否会发布  “仿真运行”错误的屏幕截图?  

    此致

    Shankari G

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

    您好、Shankari、

    下面是 Lauterbach 工具(Trace32)的屏幕截图、其中显示了尝试暂停执行(命令"break.direct")后的"Emulation running (仿真正在运行)"错误。

    如您所见、该工具报告它认为处理器仍在运行。

    Emulation Running Error in Lauterbach tool

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

    Daniel:

    对于 AM5K2E02、TI 处理器的推荐开发工具是 CCS 和 XDS 仿真器(调试探针)。

    据我所知、我认为我们无法获得 Lauterbach 工具的支持。

    客户说"(即我们连接"system.up"、加载引导加载程序、运行引导加载程序、加载映像、运行映像、 然后、它每次都在大致相同的区域内停机)"

    如果您购买了 K2E 开发板、它将会有板载 XDS 仿真器。 您可以通过加载和运行来验证同一图像。  通过这种方法、我们可以缩小调试探针、处理器停止或应用挂起等问题的范围 并检查它是否每次都在相同的代码处停止。

    此外、使用 Lauter bach 工具、尝试运行 AM5K2E02 SDK 附带的其他一些工作示例/图像。 通过此操作、我们可以缩小应用程序是否导致问题的范围。 如果您的定制板支持...、请使用 XDS 调试探针尝试相同的操作。

    此致

    Shankari

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

    您好、Shankari、

    我们确实提供了一些 XDS200探针、但我们的开发环境目前尚未设置为使用它们。 我们还提供了一些66AK2E EVM 板、但我们的定制操作系统/应用 在其当前配置中不支持该板、尤其是我们正在连接该 EVM 上未提供的大量外部器件。

    我认为我们可以将调试探针排除为原因、因为在调试器未进行物理连接时、我们仍然会遇到失速。

    我们的应用程序在没有 OS/RTOS 的情况下运行裸机;它是我们定制 RTOS 的原型。

    该应用程序目前可用作演示器和基准工具;我们拥有相同应用程序的较旧版本、其中大部分总体框架是相同的、但这些基准功能较少。 我们仍然可以运行该较旧的应用程序版本、即使在运行相同的基准测试时、我们也不会收到任何停止。

    在之前的死锁情况下、改变阵列大小(例如、允许更多基准测试运行)会导致内存布局稍微改变、运行基准测试时移动了死锁位置。 有时、锁定不会在布局更改后发生、但会在值更改后返回。

    我在启用 ETM 跟踪的情况下运行了几次应用程序;每次记录的最后一个分支点是在锁定发生之前的 IRQ/中断。 但是 、自上述正在运行的非停止应用程序以来、中断处理程序的代码尚未被触发。

    作为参考、我们有一个大约每15ms 触发一次的中断(但我们可以将其减慢至每100ms、并且仍然会停止)。 它来自 PCIe 设备的 MSI 中断。 我们的处理程序执行三项操作:1. 递增计数器。 2.清除 PCIe MSI 中断。 3.写入器件上的寄存器以指示它可以产生另一个中断。

    由于代码的性质、我不得不在迹线中模糊一些识别信息。 左侧带有减号的数字是跟踪记录编号、用于计算跟踪结束前剩余的记录数 其中、线读"ptrace"是来自 ETM 的跟踪、通常发生在存在分支或其他可追溯执行点的任何位置。 使用跟踪记录中存储的 PC 从已知源代码内插任何源代码行。

    希望这些图像显示 、中断处理程序是每次停止之间唯一常见的位置。 但是、在发生失速事件之前、完全相同的中断处理程序 会执行上千次而不会出现任何问题。  

    迹线1

    Trace 1

    迹线2

    Trace 2

    迹线3

    Trace 3

    迹线4

    Trace 4

    此外、这与跟踪4相同、但在早期的中断调用中。 这包括 IRQ 异常处理程序、但出于与上述相同的原因、我排除了中断处理代码。

    Good Trace, entering exception handlerGood trace, start of Exception handlerGod trace, end of handler & leaving

    同样、我们也非常赞赏任何有关要探测或配置哪些寄存器/地址的建议、以便让我们了解为什么内核处于停滞状态、即等待存储器事务。

    我们在内部进行讨论、 由于侧重于中断处理程序、我们倾向于将其与 PCIe 相关。 同样、如果您可以建议一些寄存器/地址;我们可以检查预失速和后失速以确认/排除 PCIe 作为原因、这会很有帮助。

    非常感谢。

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

    啊、抱歉、这里有一个快速更正:

    我们的处理程序执行三项操作:1. 递增计数器。 2.清除 PCIe MSI 中断。 3.写入器件上的寄存器以指示它可以产生另一个中断。

    在此版本的代码中、我们不会写入 PCIe 器件(这是不同的设置)。  

    此外、为了清除、我们将相应地写入相应的 mSIN_IRQ_STATUS 寄存器和 IRQ_EOI 寄存器。

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

    Daniel:

    感谢您的详细解释。

    对于 PCIe 相关问题、让我与我的团队进行讨论、然后返回给您。 (请注意、据我所知、PCIe 的支持时间有限。

    此致

    Shankari G

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

    您好、Shankari、

    关于 PCIe、我刚刚完成了一些进一步的测试。

    我启用了所有错误中断(ERR_IRQ_ENABLE @偏移量0x1C8)和电源中断(PMRST_IRQ_ENABLE @偏移量0x1D8);并且创建了这些中断的处理程序。

    在执行期间、这些中断不会触发。

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

    Daniel:

    请给我们一些时间、让我们听取 PCIe 专家的意见。

    感谢您的耐心等待。

    此致

    Shankari G

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

    当我们尝试通过对可能的勘误表实施一些修复(包括声称为 r2p4内核版本修复的修复)来缩小问题范围时、我们已经执行了完全清理和重新构建应用程序。

    完全清理和重建似乎解决了我们的问题。 自此之后、我们没有遇到过锁定情况(我们以前用于在30秒内锁定的基准测试连续运行了2个多小时、没有锁定)。

    我们不愿声称这已经完全解决了这个问题。 我们将在周末进行一次长时间的测试、以提供一些信心。

    我将在下周再次更新结果。

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

    Daniel:

    真是个好消息。  恭喜!

    正如您所说的、这似乎是间歇性问题。  

    如果时间允许、请同时分享您在勘误表中提到的修复程序、以便论坛成员了解这些修复程序。

    (Meanwhile、由于"感谢"假期、我没有听说过 PCIe、我们的专家 抱歉!)

    此致

    Shankari

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

    对拖延表示歉意。 我们的周末长试没有锁。 我们现在更有信心,这个问题与一个腐败的建筑环境有关。 因此、我们的解决方案是:在构建之前确保构建环境清洁。

    关于勘误修复;我们主要查看了 ARM Cortex-A15勘误表文档中可能导致失速、活锁、死锁等的修复 我们遵循了其中列出的修复程序(即设置适当的位、使用 DSB 等)。 但是、如前所述、这些勘误表中的一些不会影响此芯片上芯片的修订版。  

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

    谢谢 Daniel。

    很棒!