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.

[参考译文] TCI6638K2K:SoC 挂起问题

Guru**** 2584675 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/590080/tci6638k2k-soc-hang-problem

器件型号:TCI6638K2K

您好!

我们使用基于 K2KEVM 的定制硬件设计、使用带 MCSDK 3.1.1.4的 TCI6638K2K 修订版2.0

 

我们正在尝试不同的测试传感器和测试案例、实际上我们主要看到了2个交通繁忙时出现的致命问题:

  • SoC 变得无响应、看起来所有内核都冻结了。
    • 通过调试器连接后、我们可以访问 L2SRAM、但无法访问 DDR3A/B
    • 我们已经查看了芯片勘误表建议36的应用。  
    • 我们检查并联 DSP 是否在 Qmss_queuePushDescSize()挂起
    • 如果我们在连续或并行队列之间添加延迟(使用不必要的 mfenced()或通过 VBUSP 进行推送),则问题很少发生或消失(不确定是否出现此问题)。
    • 如果我们将 DDR3B 用于外部链接 RAM 而不是 DDR3A、我们不会遇到问题、我们不确定这是否是临时解决方案。
  • 我们遇到 AIF 溢出(入口)和 AIF 饥饿(入口)错误计数器递增、显示 AIF 面临大量的停转。
    • AIF 入口描述符和入口描述符分别位于 MSMC 和 L2SRAM 区域中。
    • 如果我们将一些高度使用的描述符从 Ext Link RAM 移至 Int Link RAM 区域、则仍然会出现饥饿问题、但远低于以前的情况。

我们无法找到这两个问题的根本原因、我们将感谢您的任何帮助...

谢谢、此致。。

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

    这些问题可能特别难以解决。  由于 QMSS 是系统的中央资源、因此在队列推送中查找内核并不一定意味着 QMSS 是问题所在。  实际上、QMSS 推送/弹出不会阻止、因此、如果内核在对有效 QMSS 寄存器进行读/写访问时挂起、则可能会发生灾难性事件。

    您是否能够确定首先发生什么、AIF2错误或 DSP 挂起?  从 您的描述中可以看到、AIF2内存使用可能是问题的主要部分。  由于 AIF2的时序不能在不导致严重问题(例如断开链接、描述符饥饿等)的情况下被延迟、因此建议为此使用最低延迟资源。  不应将外部链接 RAM 用于 AIF2描述符。  与大多数其他 Keystone 器件相比、K2K 的链接 RAM 增加了一倍、因此这不是问题。  您还可以将 AIF2 pktDMA 的优先级授予系统中所有其他 pktDMA (请参阅导航器用户指南的第4.2.1.4节)、但这通常不是必需的。

    如果您可以通过更改 AIF2使用的资源来使问题消失、那么延迟和/或饥饿可能是问题所在。

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

    您好!

    我想我们面临两个不同的问题:SoC 挂起问题和 AIF 饥饿问题。 我们不确定它们是否相关。

    在我们将 QMSS 外部链路 RAM 从 DDR3A 移到 DDR3B 之后、SoC 挂起问题消失了、但我们面临 AIF 饥饿问题。

    AIF 饥饿现象很少发生(@20MHz、8 AxC、2个链路、1个 PE_db_Hakation 计数器每8-10小时增加一次)在内部链路 RAM 上分配 AIF2描述符、AIF PktDMA 在 SoC 中具有最高优先级。 此外、我们可以确保 SoC Hang 发生在 AIF 饥饿之前。

    这里的主要问题是 SoC 挂起问题、因为我们不确定问题的根本原因。 在 qmss 队列中添加不必要的延迟(_mfenced()等)推送或将外部链路 RAM 从 DDR3A 移动到 DDR3B 等有助于我们克服(??) 我们的应用中的 SoC 挂起问题。 我们不确定我们是推迟还是永久解决这个问题。

     是否可能会有某种总线拥塞的原因? 例如,我在“KeyStone 连接和优先级 ”文档中阅读了有关此内容的声明。

    除了在“KeyStone II 架构天线接口2 (AIF2)”文档中这样做之外,我还阅读了下面的另一条类似声明:

    实际上、这就是我们在同一主题下发布这两个问题的原因。

    我们通过适用于 DDR3A/B 的 ProTrace 捕获了外部链接 RAM WR 事务 两种访问之间的平均持续时间几乎相同。

    提前感谢..