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.

[参考译文] AM5K2E04:KeyStone II SOC 锁定

Guru**** 2550290 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1329136/am5k2e04-keystone-ii-soc-lockup

器件型号:AM5K2E04

您好、Richard、

我们已经对我们的问题进行了进一步调查。 我们认为 PCIe 问题现已得到解决、但仍有一个我们在测试中发现非常难以解决的锁定问题。

到目前为止、我们已经调查了其中六个通过 JTAG 锁定的 CPU、并显示了不同的症状。

---
(1)在这种情况下、许多外设存储器映射寄存器都无法访问。

不可访问:I2C、UART、SPI、任何 SERDES、PLL 控制器、 网络协处理器、电源睡眠控制器、GPIO、信标系统、队列系统、 DDR PHY

但是、我们可以访问某些系统:CIC0、CIC2、EDMA0、MSMC、SDRAM (这些似乎都在 TeraNet3_C 上)。

然后、我们尝试了访问 DDR RAM。 一些访问没问题、但我们第一次尝试访问 CPU3特定的存储器区域(我们的第一个存储器访问可能缓存在 CPU3上)时、调试系统暂停、无法进行进一步调试。 我们无法再连接到 JTAG TAP。

---
(2)、(3)在这些锁定上、我们更成功地使用了外设存储器映射寄存器。 直到我们尝试访问 USB PHY。 然后调试系统再次挂起、我们无法再进行调试。 在此之前、我们已经尝试了一些 DDR RAM 存储器存取和几个外设。 我们所尝试的都可以- NET 协处理器、所有 SerDes、PLL 控制器、电源睡眠控制器、I2C、 UART、INT 控制器、CIC、GPIO、BOOTCFG

我们甚至没有在代码中启用 USB 子系统、因此出人意料的是它挂起了调试系统。

---
(4)、(5)、(6)对于其他3个锁定、我们似乎能够访问所有 DDR RAM 和已启用的外设的所有存储器映射寄存器。 访问 USB PHY 时返回错误(我们预期该错误、因为它未启用)、但它不会像(2)和(3)中那样挂起调试系统。

通过 JTAG、似乎没有什么问题、除非所有 CPU 内核都卡住。 它不建议任何特定的子系统、因为它们都处于我们期望的状态(启用时可访问、未启用时出错)。 我们目前有一台机器处于该状态。 您认为我们还可以尝试其他什么方法来解决 CPU 内核锁定的原因吗?


非常感谢您可能提出的任何建议、
时间

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

    Tim、您好!

    您已经描述了在某种问题时间在器件之间观察到的一些情况。  从几个"良好参考单位"捕获快照并比较好 A 与好 B、然后好 A 与好。 问题 A、...我建议尝试在问题日志失败的大致点从良好单元中捕获详细信息。  对寄存器和地址空间可访问性的差分分析可以提供有价值的线索。

    接下来、需要收集有关问题范围和频率的一些信息。  测试中的任何装置、故障数量和频率(1分钟、1小时、1天...)。  是它们没有发生故障的任何部件。  它们有什么不同之处?   有哪些共性?  它们是否会在应用程序数据流中的某个类似点冻结? ...

    此致、

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

    您好、Richard、

    我在这里附上了到目前为止我们拥有的信息、将好的单元与6个锁定进行比较...

    e2e.ti.com/.../Lockups.rtf

    simon gao 说:
    如何测试任何单元

    自从我们修复了 PCIe 问题后、我们还无法在测试条件下创建故障。 我们看到的唯一故障是在实际部署器件时、这会导致难以调试。

    到目前为止、实际使用的装置约有23个(它们被用于路由网络流量)。 其中7个是路由客户的互联网流量、这些似乎容易受到锁定的影响。 自 PCIe 修复以来、到目前为止其他网络使用模式尚未引起任何锁定。 在这7人中、4人似乎定期被锁定-在他们中间、我们通常每8-9天就会受到几次锁定。 7人中有2人是新部署的,但已经使用了两周,没有出现锁定。 最后一个单元在被锁闭前被关了104天。

    这3个很少锁定单元或尚未锁定的单元运行的软件版本早于其他4个单元(使用较旧的 ARM 工具链构建)、因此我们要尝试隔离软件更改是否可能导致这一问题。 由于我们的故障间隔时间是许多天、事实证明这很困难。

    simon gao 说:
    它们是否在应用程序数据流中的某个类似点冻结?

    它们并不总是在同一个点冻结。 不过、似乎有一部分地方发生冻结-总是位于寄存器或 RAM 访问处或其附近。 我们经常访问排队系统或从我们自己的网络缓冲区中读取(我们的网络缓冲区是可由1G 或10G 网络系统写入并可在 CPU 内核之间传递的内存)。 不确定为什么有些存取似乎存在问题、而大量的存储器存取从未出现过锁定。

    此外、我们不知道4次 CPU 内核访问中的哪些是冻结的发起方(或者是冻结的组合) 或者、如果它是一个外设导致内存系统冻结、然后 CPU 在下次进行特定类型的访问时会卡住。

    值得说的一件事是、即使是完全相同的软件版本也不会锁定在同一个位置。 但是、到目前为止、每个软件版本在存储器和寄存器是/不是可访问的故障模式方面都是一致的。 但我们没有太多数据、因此这可能是重合的。

    正如我所提到的、我们目前有一台机器已锁定并连接到 JTAG、不过很快就会恢复使用。 如果您能想到我们可以在该机器上探测的任何其他东西、请专门告知我。 否则、我们可能需要等待几天、然后再有机会。

    非常感谢、
    时间

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

    Tim、您好!

    lockup.rtf 和您的评论大大改善了上下文。  这看起来 lockup1可能是不同的、或者仿真器的 JTAG 探测触发了常规地址空间折叠。 如果我删除所有在好的情况下不能被触及的路径,很大程度上,它看起来所有的奴隶都是活着的。   我建议使用 DAP 来读取失速内核的 PC、以便了解它们冻结时上次执行的操作(用于 ARM 的 DBGPCSR、大多数内核提供一条路径)。  我还可以 通过 JTAG DAP 运行一个 PC 采样器来记录很长一段时间内的内核活动。  在闲置时间、可以提供 有关目前闲置的一些有用线索、以及进入闲置的粗略历史。

    您提到在本例中、CPU 被卡住。  这意味着您可以连接它们还是它们可断开(等待流水线清除以进入调试模式)?   即使无法将 PC 暂停、也可以通过 APB 或 DAP 读取其 DBGPCR。   在 TRACE32-Lauterbach 等调试器中、只需提供限定符 APB:0x

    或 DAP:0x
    对于 CCS GEL、您使用的位置* @data 或* @System_View。   我喜欢使用 TRACE32的"节点",因为它会记录到文件每个内核 PC 通过 DAP ,这甚至可以承受一个电源循环,这允许几乎无限的日志记录。  您需要对某些内容进行编程、以便 CCS 获得相同的内容、并且其采样率将降低100倍。

    一般而言、既然 PCI 已移除、最好尝试一些大旋钮测试来避开 PCB 中的任何时序或电气问题。  将逻辑 VDD 电源轨提高约+50mV 是一项很好的测试、同时也会将 CPU PLL 降低约10%。  如果故障率发生变化或影响、则需要深入研究该角度。

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

    谢谢 Richard。 我们将尝试研究这些东西。

    您注意到 soc 在这种情况下被卡住。  这是否意味着您可以连接到它们或它们是否可取消激活

    所有4个 CPU 内核都是不可停止的。 但我们已读取程序计数器、因此我们知道它们被锁定的位置。 每次它锁定时,程序计数器都不同,尽管在它将被冻结的地方似乎有一些共同点。 我们经常在队列系统(获取或排队网络描述符)或对我们自己的网络缓冲区(通常需要监控的存储器)的存储器访问中看到它。

    此致、

    时间

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

    Tim、您好!

    内核很可能会在等待内存事务完成时卡住。   如果您可以读取/写入存储器基址(假设为 DDR、但也有 SRAM)、则该从器件可能不会完全崩溃(相对于而言、这是更常见的故障)。  您应该重新验证您是否可以在 A15可能触摸到的内存挂起时读取/写入。  如果总存储器(在基本模式下工作)、则可能存在一个较小的子范围、该子范围以某种方式在用户之间死锁。  如果在存储器底部从调试器向顶部执行图形写入、可能会发现某个范围没有响应。  对于它从每个内核进行访问的方式、该范围将是1到0。  像其他主器件这样的东西在访问时被停止、而另一个内核尝试进行访问、并卡在等待中。

    此致、
    理查德·W·