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

[参考译文] LMK05318：LMK05318 在‑长期 1 μ s 现场操作后引导失败–请求指导

admin
Guru**** 2914580 points

Other Parts Discussed in Thread: LMK05318

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

https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1608836/lmk05318-lmk05318-boot-failure-after-long-term-field-operation-request-for-guidance

器件型号： LMK05318

你（们）好  

客户观察到 A 正常运行~1.5 个月后与 LMK05318 发生的现场问题 。

  • 大约、系统在客户环境中一直正常工作 1.5 个月
  • 上周、客户找到了该系统 无法引导 、和 MAC 无法启动
  • 根本原因跟踪表明问题与相关 LMK05318 无法正确引导
  • 多次下电上电未恢复器件
  • 到目前为止,共享了 ISP 文件和脚本以编程 LMK。 现在,系统恢复与.   >>“qnc4_after_LMK_recover.txt"</s>“

 

客户捕获了以下数据：   >>“qfx5140_working.txt"和“和“r4qfx5140qnc_faultyhw.txt"</s>“

  • 来自 A 的寄存器转储 正常工作 频率
  • 来自 A 的寄存器转储 不‑μ A 工作 频率
  • 两个器件的 EEPROM 映像转储

‑比较了工作和非工作结果并发现： >>“捕获了工作和非工作设备的寄存器转储和 EEPROM 转储 Result.txt“

  • 不同之处 寄存器值
  • 不同之处 EEPROM 映像内容
  • 似乎存在一些差异 LIVE/STATUS‑related 而其他情况也可能如此 配置或 NVM 相关
  • 我们仍在审查预期与意外之间的差异

‑比较了不工作的 I ² C 和重新编程结果、发现：>>“捕获了不工作设备的寄存器转储和 EEPROM 转储并恢复了 Result.txt“

我们感谢 TI 在以下方面提供指导：

  1. EEPROM/NVM 损坏
    • ‑是否存在确保 LMK05318 EEPROM 内容在长时间的现场操作后可能损坏的已知情况？      （到目前为止，在发生此问题的 DUT 上对 LMK 重新编程后看起来不错）
  2. 引导/CRC 指示器
    • 应首先检查哪些寄存器或 CRC 指示器、以确认 EEPROM 在引导时是否成功加载？
  3. 寄存器比较指南
  • 0
    TI__Guru**** 2914580 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Nelson：  

    EEPROM 内容可能会在长期运行后损坏。 但是、由于我们在编程后测试了工厂的老化数据保留情况、因此这些故障通常极其罕见。 要检查引导后是否成功加载了 EEPROM、我建议检查 NVMCRCERR (R157[5])= 0、并且 NVMSCRC (R155) 是否与 NVMLCRC (R158) 匹配。 我们在编程手册的 R158 说明中对此提供了更多详细信息：

    “NVM 实时 CRC：该字段保存器件初始化期间根据 EEPROM 数据计算出的实时 CRC。 在初始化期间、内部 EEPROM 控制器执行 CRC 校验、以将实时 CRC 值与最后一个 NVM 编程周期中写入 EEPROM 的存储 CRC 值（NVMSCRC 字节）进行比较。 如果实时 CRC 值和存储的 CRC 值匹配（无 CRC 错误）、则 EEPROM 数据有效、器件控制器允许继续正常启动操作；否则、如果实时 CRC 和存储的 CRC 不匹配（检测到 CRC 错误）、则 EEPROM 数据被视为无效、控制器在寄存器加载后停止启动操作（例如 PLL 锁定序列等）。 可以从 NVMCRCERR 位读取 CRC 错误状态。“

    由于在检测到 CRC 错误后器件运行会暂停、因此与正常单元相比、许多器件寄存器可能会显示不同的值、即使在进行编程后 EEPROM 中只有 1 位发生翻转也是如此。 每个特定器件还具有一些出厂时存储在 EEPROM 中的校准/修整值。 如果需要验证器件的 EEPROM 内容是否与您的映像匹配、我建议转储 EEPROM 内容并将其与 TICS Pro 中生成的.EPR 文件进行比较。 我预计大多数字节应该匹配、但您可以排除字节 0-9、26 和 27、因为预计这些字节会因器件而异。 如果您有任何其他问题、请告诉我。  

    此致、  

    Connor

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

    尊敬的 Connor：

    再次感谢您以前的支持。
    我已经完成了故障 LMK05318 器件的 EEPROM 转储与 TICS Pro 生成的.EPR 文件之间的详细比较。

    ‑是基于比较结果的几个后续问题：

    关于 EEPROM 字节 0–8 (EEPROM_IMG_IDX00 ~ EEPROM_IMG_IDX08)

    根据您之前的说明、我们了解了这些字节 0–9 ‑包含器件特定的修整或校准数据、并且可能因器件而异。

    在将 EEPROM 转储与.EPR 文件进行比较后、我们观察到了这一点 EEPROM_IMG_IDX00~08 不同 、但这似乎与您对预期变异区域的描述相符。

    问题：

    您‑确认在 IDX00–IDX08 中观察到的差异是预期的器件唯一修整/校准值、不应将其视为配置损坏？

    关于 EEPROM_IMG_IDX249 ~ EEPROM_IMG_IDX255

    在转储文件中、我们可以看到 IDX249-255 的值、但这些索引不会出现在 TICS Pro 生成的.EPR 文件中。

    我们找到 TI 文档表明这些高位地址存在、但不直接映射到寄存器、必须通过 SRAM 进行编程。

    问题：

    您能否阐明 EEPROM 字节 249-255 代表什么、以及它们为什么不包含在.EPR 文件中？
    ‑器件的‑字段、保留字段还是可选的用户可编程字节？

    3.是否应将 EEPROM 内容视为“匹配“

    根据我们的比较、 大多数 EEPROM 字节完全匹配 、但以下情况除外：

    • 预期的修整区域 (IDX00–IDX08)
    • 一些高‑索引字节 (IDX249–IDX255)

    问题：

    从您的‑来看、我们能否得出结论：除了器件的特定修整字节之外、故障 LMK05318 中的 EEPROM 内容实际上与.EPR 文件的配置相同？
    或者、是否有任何不匹配的字节看起来异常？

    4、根本原因问题:即使在多次下电上电后,重复的 CRC 不匹配

    在对器件重新编程之前、请使用 LMK05318 始终引导进入 CRC 不匹配模式 ,‑多少次它是电源循环.
    EEPROM 重新编程后、器件再次正常运行。

    问题：

    鉴于 EEPROM 内容与.EPR 文件基本相同、
    边际位翻转或与 CRC‑相关的内部状态是否可能会导致器件永久停止引导、直到重新编程？
    换言之：
    我们是否应该进一步研究底层条件（电源，复位，内部状态机，NVM 磨损等）、因为器件在每次重新写入 EEPROM 之前都会继续失败 CRC？

    谢谢你

    Nelson

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

    尊敬的 Nelson：  

    请在下方查看我对您问题的反馈：  

    1.这是正确的, IDX00-08 的值预计与基本.EPR 文件不同,不应自动被视为损坏。  

    2. IDX249-255 是不链接到任何特定寄存器的备用字节。 默认情况下、我们在.EPR 文件中排除这些字节

    3、 正确、除了特定于器件的位之外、EEPROM 内容似乎与.EPR 文件匹配。 我也可以再次检查是否有任何修整/校准值看起来异常、我明天应该能够回复您、并提供一些相关反馈。  

    4. 如果 EEPROM 本身存在位翻转、预计每次启动时都会出现 CRC 故障、直到重新写入 EEPROM。 在将 EEPROM 内容加载到器件的动态寄存器空间后、每次启动时都会计算实时 CRC 值。 如果实时 CRC 与 EEPROM 编程期间设置的存储 CRC 不匹配、则将报告 CRC 故障、这将停止启动过程。  

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

    尊敬的 Connor：

    再次感谢您在上一次答复中所作的详细说明。
    我想跟进您提到的一个项目：

    “我还可以再次检查是否有任何修整/校准值看起来异常、我明天应该能够回复您、并提供一些相关反馈。“

    我可以检查是否有任何有关修整/校准字节审核的更新？
    我们希望确认校准区域在您这边是否完全正常。
    此外、由于我们的 EEPROM 转储（不包括 TRIM 字节和备用字节）与.EPR 文件匹配、我们现在正在尝试确定下一个可能的根本原因。
    该 LMK05318 器件已使用约 1.5 个月、并且在此期间已经经历了多次下电上电。 CRC 错误仅在最近发生、并且器件只能在重新写入 EEPROM 后恢复。
    您能告诉我们应该进一步调查哪些领域吗？
    例如：

    #1. NVM 中的电位‑翻转机制
    #2‑上电期间可能导致 CRC 计算错误的条件
    #3.重置定序灵敏度
    #4.EEPROM 磨损/裕度/保留注意事项
    #5. ‑2 μ s 长期使用后可能导致 CRC 不匹配的任何已知临界情况

    您的指导将‑我们是否随机发生故障、或者我们是否应该增强系统设计以提高长期稳健性。
    再次感谢您的支持。
    此致、

    Nelson

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

    尊敬的 Nelson：  

    我再次与我们的测试工程团队核实、他们确认 EEPROM 字节 0-5 因器件而异。 字节 6-8 实际上应该使用每个器件的相同值进行硬编码、因此这些字节似乎在您的故障单元中已损坏。 预期值如下、 字节 6-7 的内容也与您的.EPR 文件匹配：  

    EEPROM 字节 6：0x89

    EEPROM 字节 7：0x20

    EEPROM 字节 8：0x0C

    我怀疑这是随机故障、因为在现场一段时间后我们没有遇到很多 EEPROM 故障的情况。 我将在内部再次咨询我们的团队、看看是否有任何关于系统设计问题的报告、这些问题会随着时间的推移而给 EEPROM 带来压力。

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

    尊敬的 Nelson：  

    我仍在等待我们团队就任何可能随着时间的推移而降低 EEPROM 性能的系统应力提供更多反馈。 同时、您是否还能提供发生 CRC 错误的器件的顶部标识？  

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

    尊敬的 Connor：

    顶部标记如下所示

    LK05318B

    TI 39I

    AGXR G4


    ‑您提供有关 EEPROM 字节 6-8 的后续信息。

    我对我们目前拥有的其他两个装置进行了额外检查。
    两个单元都能正常启动而没有任何 CRC 错误、但在转储 EEPROM 后、我发现了这一点 EEPROM 字节 6–8 实际上并不相同 在这些工作单元之间、它们也与提供的预期固定值 (0x89、0x20、0x0C) 不匹配。

    为了更好地理解这种情况、我将这些值与中的寄存器定义进行了比较 “LMK_snau254e_registers_map.pdf"</s>“ 、具体来说就是的定义 R8（字节 8） OP_MODE 字段编程。

    根据文档：

    • 我们的 HW_SW_CTRL 引脚从外部下拉至“0"。“。
    • 因此、OP_MODE = bit[2：0]预计为：
      0x2 = EEPROM + I2C、软引脚模式[HW_SW_CTRL = 0]

    但是、我们观察到的实际值如下：

    ●μ s EPR 文件

    • R8 = 0x12
    • OP_MODE =位[2：0]= 110B (0x6) →数据表中未定义此模式。

    ●μ s DUT‑P1（工作单元）

    • R8 = 0x94 (148)
    • OP_MODE =位[2：0]= 100b (0x4)
      →“EEPROM + SPI、Soft Pin Mode“、支持该模式 不会 硬件引脚设置相匹配。

    ●μ s DUT‑P2（工作单元）

    • R8 = 0x26 (38)
    • OP_MODE =位[2：0]= 110B (0x6)
      →再次是未定义的操作模式。

    LMK05318 的原理图

    e2e.ti.com/.../LMK05318_5F00_Schematic_5F00_20260226.pdf

    需要澄清的问题

    1. 即使字节 6–8 与“固定值“不同、两个工作单元也正常运行、并且 OP_MODE 字段与硬件配置不匹配：

      • 您能帮助阐明 LMK05318 中字节 6–8 的实际作用吗？
      • 对于所有器件、这些字节肯定应该是恒定的吗？

    2. 对于 R8（字节 8）、我们读取的 OP_MODE 位与文档定义和预期行为不匹配：

      • 是否有任何其他规则或内部覆盖来确定 OP_MODE？
      • 这些字段是否可能没有完全按照寄存器映射文档中所述的那样使用？

    我们感谢您的持续支持、并希望了解是否预计会出现这些差异、或者这些差异表明除了故障器件上损坏的字节之外还有另一个潜在问题。

    再次感谢、
    Nelson

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

    尊敬的 Nelson：  

    您能否确认正在按照数据表中提供的说明读回 EEPROM 转储（请参阅下文以供参考）？ EEPROM 映射不是与寄存器映射的 1：1 直接映射、因为寄存器映射为 435 个字节、EEPROM 仅为 256 个字节、因此某些字段会被排除或已移动到不同的地址位置。 我们尚未公开披露此器件的 EEPROM 映射、但字节 6-8 应使用与 PLL1 相关的修整值进行硬编码。  

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

    尊敬的 Connor：

    跟进我们的讨论：

    1. 读取方法确认
      我们已经向我们的软件团队确认、EEPROM 转储过程严格遵循 数据表第 8.5.8 节（读取 EEPROM） ：
    1. 综合不同单位的比较
      为避免误解：我之前分享的 EEPROM 转储是 和 DUT 、不重复读取同一设备。
      为清楚起见、我已将多个装置的转储合并到中 一个 Excel 文件 （随附）、带 突出显示的字节 6–8 以便并排比较。
    • PHASE1 和 PHASE2 构建： P1 和 P2  
    • 每相位单位： DUT1/DUT2/DUT3
    • 观察结果： 字节 6-8 因单位而异 、有些与您提供的固定值不匹配。
    • 所有这些单元 正常启动 没有 CRC 错误（早期的故障单元已在 EEPROM 重写后恢复）。

    1. 请求/后续步骤
    • 请您再次确认是否 字节 6–8 类型 PLL1 相关修整值 和 应在所有器件上相同 ？
    • 类型 字节 6–8 的 CRC 覆盖范围 在启动时使用？
    • 考虑到多个工作单元在字节 6-8 处也显示差异、您是否推荐任何 其他检查？ （例如，‑上电‑，欠压 Δ V OUT，复位时序）  

    附件：

    错误的硬件 转储日志：“r4qfx5140qnc_faultyhw.txt"</s>“

    硬件故障恢复（重新编程）：“qnc4_after_LMK_recover.txt"</s>“

    不同单位的比较： “ diff-DUT 转储 EEPROM.xlsx“

    e2e.ti.com/.../diff_2D00_DUT-dump-EEPROM.xlsxe2e.ti.com/.../5852.r4qfx5140qnc_5F00_faultyhw.txt

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

    尊敬的 Nelson：  

    我会继续将此主题标记为“已解决“、因为讨论已移至电子邮件。  

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

    尊敬的 Connor：

    明白了、让我们在 th 电子邮件中继续讨论。