• 状态
  • 已锁定 已锁定
  • 回复 7 回复
  • 订户 0 订户
  • 视图 1 视图
  • 用户 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.

[参考译文] AM6422：AM6422 BIST 工具支持

admin
Guru**** 2868720 points

Other Parts Discussed in Thread: AM6422

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1635174/am6422-am6422-bist-tool-support

器件型号： AM6422

1.场景:

我们需要将 BIST 工具与 memtester AS 结合使用 验证 LPDDR4 时序参数的基础 。 该测试必须包含在所有设备工厂验证和故障设备的问题回归中。

2.问题:

当前遇到的问题 异常系统挂起、数据覆盖、包括内存指针覆盖 。 但是、加电初始化训练 100%成功。 该问题仅在长期运行期间发现、很难重现 。 时间间隔从 3 天到 2 周不等、并且经常出现在少量设备出现故障的机器上。

3.工具要求

我们需要 BIST 检测控制器和芯片、以及器件识别和硬件链路运行状况。

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

    Zheng、  

    请帮助我了解此处要求的内容。 听起来 DDR 设计或配置有一些边缘性、可在长时间运行后导致存储器损坏。 但是、您可以指定数据会覆盖、而存储器指针会覆盖。 您是否怀疑内部存储器损坏（包含指令代码或 DDR 存储器内容损坏和/或对 DDR 的访问）？

    关于 BIST、您是否专注于测试 DDR 运行状况？ 如果故障可能需要数周时间才能观察到、您如何预测在工厂验证期间识别此问题？

    您是否了解有多少%的器件出现故障？

    非常感谢您提供的任何反馈、帮助您了解所需的调试和支持课程。 我不清楚您是尝试优化和解决 DDR 故障、还是正在寻找一种运行时解决方案来识别和报告发生的故障。  

    谢谢、

    Chris  

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

    您好、Chris、  

    屏幕截图显示了捕获的内核错误日志。 通过以下指令引用指针 X3 时发生崩溃： LDUR X5, [X3, #-16]。
    跟踪返回 X3 的原点,前一个指令是 LDR X3, [X0, #0x18],这是一个 ARM64 加载指令。 在内部、CPU 启动了一个读取请求、从存储器地址中获取数据 X0 + 0x18 并将其存储到 X3 中。
    基址 (X0) 为 ffff0000102661b8。
    对于涉及偏移的目标地址计算 0x18： ffff0000102661b8 + 0x18 = ffff0000102661d0。
    同样、对于指令 LDR X4, [X0, #0x8]、CPU X0 + 0x8  将数据从地址读取到 X4 中。
    目标地址为 ffff0000102661b8 + 0x8 = ffff0000102661c0。
    但是、从日志中可以看到、读入 X3 和 X4 的值在其低位字节中会显示地址残留。 如图中突出显示的那样（例如，和） ..ff..00..26..c0  ..ff..00..26..d0、数据似乎包含地址本身的残余。

    LDR 指令的硬件路径分析
    我们分析了 LDR 指令的硬件路径：CPU 内核→L1 高速缓存→L2 高速缓存 (LLC)→DDR 控制器→PHY→物理 DDR。
    在此基础上,我们提出了两个假设:
    1. 解决时序训练问题导致的外部总线上残留的问题。
    2. 信号串扰。
    排除假设
    以下分析排除了这两种原因：
    1.在 LPDDR4 中、引脚功能被严格分离：CA 引脚专用于命令和地址（行，列，组）、DQ 引脚处理数据、DMI 引脚在屏蔽写入期间管理掩码控制。 没有将地址信号多路复用到 DQ 总线的机制。 因此、我们可以排除由硬件链路或颗粒缺陷引起的总线残留物。
    2.  PCB 堆叠和串扰分析
    CPU 板采用标准 10 层堆叠。 DQS、DQ 和 DM 信号在第 3 层布线、而 CA、CK 和 CKE 信号在第 8 层布线。 这些信号层由两个电源平面和两个接地平面隔开。
    鉴于这种标准结构和中间平面提供的有效屏蔽、我们可以有效地消除 PCB 上的外部串扰。
    深入分析：AM6422 PHY 方向开关故障
    进一步的分析指出、AM6422 SoC 内部 DDR PHY 中的“读取/写入开关逻辑故障“是主要故障问题。 在芯片级调试中、这通常称为“总线转弯泄漏“或“方向开关死锁“。
    架构环境中
    DDR PHY 定义了存储器控制器 (MC) 和外部 SDRAM 之间的物理接口。 它包含数据路径和负责切换 DQ 引脚方向（输入/输出）的 I/O 逻辑模块。
    机制扣减
    1. I/O 缓冲器架构 :在 PHY 内部,每个 DQ 引脚对应一个双向 I/O 缓冲器 (PAD),它包含一个发送驱动器、一个接收比较器和一个方向控制开关。
    2. 转弯时序 ：在读取命令之后、PHY 必须经过总线周转时间才能将缓冲区从“发送模式“切换到“接收模式“。
    3. 故障触发 :由于温漂、电压下降或 PHY 状态机错误,方向开关可能无法及时完成。 在外部数据到达之前、发送驱动器可能无法关闭 (GO Hi-Z)。
    4. 形成“环回漏电流“ ：
      • 残留驱动器 :在读取之前,总线执行写入或命令传输,在内部总线上留下残留的地址/数据级别。
      • 潜在问题 :由于开关滞后,内部发送驱动器的弱传导将这些残余电平（前一个地址）拉至 DQ 引脚,从而覆盖来自外部 DRAM 的弱信号。
      • 错误采样 : PHY 接收器对该“受污染“引脚进行采样,捕获 SoC 自身的地址残留物,而不是从 DRAM 获取数据。
    现象说明
    • 数据类似于地址 :读取的数据实际上是以前在总线上的地址。
    • 逐位差异 ：字节通道之间的负载和延迟变化会导致不一致的切换。 高位缓冲区的切换速度可能足够快、以便接收正确的数据、而低位位缓冲区的切换速度较慢、从而会出现“泄漏“和捕获地址残留。
    因此、我们请求 TI 协助调查这个主要嫌疑人。 我们还寻求有关诊断工具的建议、例如使用 PHY 内部环回模式进行验证。
  • 0
    TI__Guru**** 2868720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Zheng、  

    您似乎怀疑访问 DDR 时可能发生数据损坏。 您能否在已知故障的主板上通宵运行 memtester？ 这将有助于运行数据模式、这些模式可能会显示是否存在可能导致此问题的边缘故障。 如果我们排除 DDR 稳定性、我们可以开始研究运行时软件以查看加载指令是否是导致问题的原因。 如果 memtester 显示故障、我们可以检查 DDR 配置并尝试识别改进措施以消除故障。  

    我还会在此主题中添加 DDR 和软件专家、以便在获得反馈后进行监控。  

    谢谢、

    Chris  

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

    您好、Chris、

    由于我们已经分析了很长一段时间,我们最初怀疑它是一个软件问题。 因此,我们在一开始就进行了相关的记忆压力测试。 附件是电路板上的测试记录、其中包含我们之前执行的已知问题。

    我们为软件实现了许多模块隔离和状态监控功能。 然而、不幸的是、没有得到有价值的结论。 但我们提出的关于反汇编后底层指令的内存访问的当前现象基本上可以归因于物理层的故障。 我想知道这是否正确？
    附件包含两个原始错误日志以供参考、以及 memtest 的应力测试日志以供进一步参考。
    e2e.ti.com/.../Serial_2D00_COM11_2D00_20260411.log
    e2e.ti.com/.../session_2D00_2026_5F00_04_5F00_05_5F00_Serial_2D00_COM8_5F00_serial_2D00_2.log
  • 0
    TI__Guru**** 2868720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    所有四个 memtester 日志都不会显示任何问题。  它们是否与您的预期工作温度一致？  通常、极端温度有助于揭示边缘问题。  尝试长时间运行 memtester 以及最低和最高工作温度。

    您能否从您在代码中使用的 DDR 寄存器配置工具中提供 DDR 数据表和 DDR 配置 (.dtsi 和.syscfg) 文件？  我可以尝试检查配置是否有任何错误。

    此致、

    James

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

    我们已经在 65°高温和–35°低温下测试了有问题的电路板、并且未发现任何问题。 对于没有问题的电路板、我们还在高温和低温下进行了长期压力测试、运行了两轮。 第一轮持续了 4 天,第二轮持续了 3 天。

    e2e.ti.com/.../first-round.zipe2e.ti.com/.../second-round.zip

     此外、我们还附加了当前使用的 DTSI 文件。   

    e2e.ti.com/.../currently-in-use.zip

    我们同时创建了许多不同的文件,试图加速解决不断恶化的问题,但在更新这些 DDR 配置后,没有重大的变化。 因此、目前我们无法确定它是否与配置有关。

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

    您能否发布我们在通话中讨论过的、在运行 8 天的 4 块主板上使用的最新配置？  我想将测试重点放在这种配置上。  原始 DDR 配置是使用该工具 v0.8.10 生成的、该工具使用了几年之久、此后进行了多次更新和优化、以提高生成的配置文件的稳健性。  我相信在通话中显示的错误可能会通过其中一个工具更新得到解决。   我还建议增加几块电路板来使用这种新的 DDR 配置进行测试、在极端温度下运行电路板以进一步强化配置。

    此致、

    James