[参考译文] LMK05318B：：LOS_XO &amp；LOS_reference

尊敬的 PF：

1. 看起来您附加了寄存器的 hex 文件(.txt)而不是 TICSPRO GUI 文件(.tcs)。 您能否通过转至"File -> Save (文件->保存)"共享.tcs？
2. 能否探测 XO 输入(TCXO)？ 可能是短路、或客户电路板上的信号不稳定。 如果 XO 变为无效、这将影响 DPLL 锁定、从而触发 REFSWITCH。 由于 XO 间歇性发生故障、因此器件看起来像是在保持(XO)和 DPLL 锁定(REF)之间切换。
3. 您能解释一下他们看到了什么吗？
   1. 是... 上电 ->清除中断->等待一段时间->回读中断-> XO INTR 为0 (通过)
   2. 或者说……power-up --> Clear interrupt -> XO INTR 失败->清除中断-> XO INTR 失败->清除中断-> XO INTR 失败(基本而言、即使实时 LOS_XO 保持清除状态、XO intr 也会进行切换。)

此致、

Jennifer

Jennifer、您好！  

感谢您的反馈。  

1. 我编辑了原始帖子、并添加了 TCS 文件、而不是 txt 文件。
2. 这也是我的假设。 我探测过 TCXO 信号、未发现任何问题。 此外、我甚至使用了来自应用板的信号并将其馈送到 EVM 板的 XO_P 中、因此不会发生此问题。 这指出了我的电路板上的 LMK 或替代元件的一些问题的方向。
3. 上电后、我清除中断源并直接读回。 XO_INTR 始终为1。 实际上、我从来没有看到该中断寄存器为0。 这句话、从你的角度很好地描述它："基本上 XO intr 切换 、即使实时的 LOS_XO 保持清零。"

当检查 OUT6 CLK 时、这"看起来"一直锁定到 PRIREF 输入。

LOS_XO 这段短时间似乎会导致非常短的保持事件、该时间不足以满足解锁事件的要求。

BR、PF

尊敬的 PF：

1. 我使用信号发生器作为 LMK05318BEVM 的 XO 输入、测试了.tcs 文件。 我没有看到 LOS_XO_INTR 切换。  
2. 当将 XO_P 馈送到 EVM 板时、EVM 是否使用与应用板相同的电源？ 本质上、EVM 应配置为"直接 VIN/LDO"以绕过板载 VDD。
3. 能否探测 XO 电源？ 可能 XO 电源不稳定。
4. LOS_FDET_XO_INTR 是否也在切换？

此致、

Jennifer

Jennifer、您好！

1. 感谢您的验证  
2. 我使用 EVM 的板载 LDO 并通过5V 电源为其供电。 我会进行测试、以便将3V3直接从我的应用板馈送到 EVM、并绕过 LDO。
3. 您是指外部 TCXO 的电源还是 LMK 的 VDD_XO 电源引脚的电源？ 我将板载 LDO 从3V3更改为干净的1V8电源、结果仍然相同、电压容差是否存在限制？ 其他问题、是否可以更改使 XO CLK 合格的监控器？
4. 否、该位未置位。

进一步的测试。  

• 从 实验室电源 向应用提供干净的3V3 (在 LDO 之后)显示相同的错误
• 为 EVM 向应用板提供 XO 时出现了同一问题

刚刚测量了3V3_SMPS 电源轨(黄色)与1V8_LIN 电源轨(TCXO 的或电源)的频谱噪声密度(&)  

还 测量了3V3_SMPS 电源轨(黄色)与3V3_SMPS_Bead 电源轨(LMK 为橙色、电源)的频谱噪声密度  

尊敬的 PF：

1. "您是指外部 TCXO 的电源还是 LMK 的 VDD_XO 电源引脚的电源？ 我将板载 LDO 从3V3更改为干净的1V8电源、结果仍然相同、电压容差是否存在限制？"
   1. 我指的是为 TCXO VDD 的电源供电。 LMK 的 VDD_XO 需要3.3V 的电压。
2. "其他问题、是否可以更改使 XO CLK 合格的监控器？
   1. 否、无法更改 XO 的设置。 但是、由于您说 XO FDET 未被设置、这可能表明它是摆幅问题。 您能否探测并发送 XO_IN 引脚的示波器捕获、以查看 LMK 收到的内容。
3. 您是否有其他解决此问题的应用板？ 我想知道应用电路板上的 LMK 是否焊接不当。 是否可以使用新的 LMK 芯片进行检查？
4. 关于频谱噪声密度图、我不考虑 LMK 电源上的噪声、因为由于在电源引脚上集成了 LDO、LMK 具有出色的 PSNR 性能。 我会更考虑使用 XO、因为由于电源引脚上缺少内部 LDO、它们通常对噪声敏感。 您能否说明一下用来捕获这些频谱噪声图的仪器？

此致、

Jennifer

尊敬的 PF：

1. 感谢您澄清用于采集数据的仪器。 我目前没有看到电源问题是导致该问题的原因。
2. 您共享的图正在 LMK 的 XO_IN 引脚上探测？
3. 您能否将所用的 LMK05318B 原理图连接起来？

此致、

Jennifer

Jennifer、您好！

是的、直接在 XO_P 输入端探测这些图。

请参阅随附的原理图。

尊敬的 PF：

我也没有看到原理图有任何令人惊讶的错误。

您能否提供 PDN、3V3和1V8电源轨的启动示波器图？ 我想确保斜坡时序正确发生。

此致、

Jennifer

Jennifer、您好！  

请参阅随附的斜坡时序的屏幕截图。

黄色= 3V3_SMPS (VDDIN、VDD_PLL1、VDDPLL2、VDDDIG)

蓝色= 1V8_LIN (VDDOx)

绿色= 3V3_LIN (TCXO 的电源)

红色= PDN (使用内部100kr 以及一个外部 C)

尊敬的 PF：

我已经与我的团队进行了讨论、我们还需要您检查以下事项：

1. 您的电路板是否有电流限制？
   1. 检查的一种方法是探测每个 VDD 和 VDDO 引脚(包括外部 XO)。 它们都读取3.3V 还是1.8V？ 我们建议使用示波器进行检查、因为它可以提供有关是否发生纹波或意外脉冲的见解。
2. 当使用电路板的电源为 EVM 供电时、是否还有其他器件连接到系统？ 如果您将其他器件断电而仅为 LMK05318B 供电、结果是否存在差异？ 如果将所有器件连接在一起、会怎么样？
3. PDN 引脚需要多长时间才能达到3.3V？
4. 您是否可以尝试对 XO 输入进行交流耦合？ 在过去、我们尚未看到过直流耦合 XO 信号的问题；但是、需要检查的另一点是确保直流噪声不会被消除。

此致、

Jennifer

Jennifer、您好！

1. 我探测了所有电压轨、发现任何可疑情况。 还 通过实验室电源为3V3和1V8应用板供电、无改进。
2. 我已经开始调查并关闭了微控制器的电源。 我必须将 I2C/SPI 编程器连接到 LMK 以读出状态、但看起来这种情况将 LOS_XO 中断的行为更改为 LOL_APPL1。 我明天会进一步调查,以确定这一点。
3. PDN 需要~120ms 才能达到3.3V。 但我已经使用更高/更低的电容值进行了实验、结果没有任何效果。
4. 这只是为了澄清。  
   1. TCXO 应通过100nF 电容馈入 XO_P
   2. XO_N 引脚应直接接地还是通过100nF 电容器连接到 GND？

尊敬的 PF：

感谢您的更新。 请在项目2上发布我的信息。

1. TCXO 应通过100nF 电容接入 XO_P -->[JB]是的、但应确保电阻器的设置符合数据表规格(1Vpp 到2.6Vpp)
2. XO_N 引脚应直接接地还是通过100nF 电容器连接到 GND？ -->[JB]编号 保持至 GND、无电容器、这是可以的。

另一个问题是、您是否在每次上电时通过 I2C 编程？ 或者您是否在每次上电时使用 EEPROM 配置对 EEPROM 进行编程？

Jennifer、您好！  

系统具有以下顺序：

POWERON -> LMK 从 EEPROM 加载其配置+ SPI ->针对 µC μ s 释放的延迟复位、而且来自 LMK 的输出频率已可用

1. 交流耦合 XO_P 未表现出任何差异
2. 将系统更改为 ROM+I2C 模式、并从外部为 μ µC 提供正确的频率。
   1. 我将外部 I2C 编程器连接到 LMK 并加载相同的 TCS 配置、结果不错、一切正常工作。 由于 μ µC 现在从外部获得频率、因此整个电路板和其他功能也将运行。

至少这在某种程度上是有意义的、因为 HW-CONFIG 现在对于 EVM 来说是识别的(ROM+I2C)、我在其中初始测试了所有内容并正常工作。

但这让我有一点闭塞、在哪里查找问题或根本原因以及如何解决此问题。

我无法使用 ROM+I2C 模式、因为电路板上没有 I2C、并且当 LMK 未以正确的频率配置(在本例中、按 μ µC 编程为 LMK)启动时、μ µC 无法运行。

尊敬的 PF：

您是从哪个位置加载的 EEPROM + I2C 或一些 ROM 页( ROM + I2C )？ LMK05318B 具有 EEPROM 和 ROM。 在 ROM 不是的情况下、EEPROM 可由用户修改。 在下一个数据表版本中、将弃用/删除 ROM 特性(主要是因为未使用 ROM 页、这会导致与 EEPROM 混淆)。

如果您认为正确的频率和结果良好、您谈论的是使用 TICSPRO 中提供的配置还是 EVM 默认配置？

此致、

Jennifer

Jennifer、您好！

默认设置为：从 EEPROM 加载+SPI -我有这个问题

按测试将 I 更改为：从 ROM+I2C 加载(并且必须稍后通过 I2C 发送至 CONFIG)-有效

我还试过测试。

1. 将 EEPROM 编程到所有寄存器中的00
2. 从 EEPROM + SPI 加载
3. 通过 SPI 将配置写入 LMK (输出频率和锁定在那里)、但变量 LOL_APPL1和 LOS_XO 仍被置位  

尊敬的 PF：

1. 不建议将00写入 EEPROM。 如果不使用 EEPROM、我建议您使用随附的出厂默认配置刻录 EEPROM。
   1. e2e.ti.com/.../LMK05318B_5F00_STD_5F00_EEPROM_5F00_CFG_5F00_v2.txte2e.ti.com/.../LMK05318B_5F00_STD_5F00_EEPROM_5F00_CFG_5F00_v2.tcs
2. 当您通过 SPI 进行编程时、您是否已通过获取寄存器转储读回并将其与预期文件(尽管忽略只读寄存器)进行比较来确认寄存器已正确写入？
3. 借助外部 I2C 测试、您可以尝试使用 EEPROM + I2C 进行测试吗？ 如果 ROM + I2C 可以正常工作、那么 EEPROM + I2C 不会正常工作的原因。

此致、

Jennifer

您好、Jennifer、明天检查您的建议。

是否还有一个"默认"ROM 配置、您可以在此处将其作为寄存器格式共享并将其加载到 EEPROM 中？

您好、PF、请使用上述 txt 文件作为要使用的默认配置。

此致、

Jennifer

Jennifer、您好！  

1. 只需将您的文件刻录到 EEPROM、然后根据我的应用程序设置进行重新配置、没有区别。  
2. 还针对我的设置向 EEPROM+I2C 进行了检查、一切都运行正常。
   1. 保持相同的 EEPROM 融合并更改为 EEPROM+SPI 启动再次显示要设置的 LOS_XO/LOS_APPL1位。

尊敬的 PF：

您是否进行了文件比较以确认 SPI 写入操作正确？

此致、

Jennifer

Jennifer、您好！

是的、SPI 读取文件与编程的文件匹配。  

进行读取和比较会产生以下差异。

e2e.ti.com/.../Untitled.txt

最新动态：  

1. 我通过现有的 µC 修改了应用 PCB、使其与 EEPROM+I2C 兼容、并更新了相关的驱动程序。
2. 将配置刷写到 EEPROM 中并从 EEPROM 启动->未设置错误位
3. 改回 EEPROM+SPI (只是将 HW_SW_CTRL 从0更改为悬空)会导致设置各种错误位

在这种情况下、刷写是由 I2C 完成的、从 EEPROM+I2C 启动没问题、而从 EEPROM+SPI 启动则不起作用。

尊敬的 PF：

请确认以下信息：

1. 上述寄存器文件比较了 EEPROM 编程后的预期值和下电上电。
2. 您是否遵循列出的注释、其中 HW_SW_CTRL、STATUS0和 STATUS1必须在 PDN 之前悬空或偏置到 VIM？ 您能否捕获与 PDN 相比这些引脚斜升的示波器快照？

此致、

Jennifer

Jennifer、您好！  

请参阅所附上述信号的启动。

全部器件在 PDN 释放之前从0.8V 开始、但 STATUS0和 STATUS1在 PDN 达到1.2V 之前降至0V

我这边不使用 STATUS0/1、而只是连接到 PU/STATUS、PD 如原理图中所示。

绿色= PDN

蓝色= HW_SW_CONTROL

红色=状态0

黄色=状态1

白线= 1.2V

尊敬的 PF：

您能否尝试将 HW_SW_CTRL、STATUS0和 STATUS1悬空而不是对0.8V 偏置使用分压器？

此致、

Jennifer

Jennifer、您好！

将这些引脚悬空时没有区别。

尊敬的 PF：

STATUSx 引脚是否也会像波形捕获中一样下降电压(在将 HW_SW_CTRL 和 STATUSx 引脚悬空时)？

此致、

Jennifer

Jennifer、您好！  

请参阅附加的测量(在 STATUS0/1悬空和保持 PD HW_SW_CTRL 的 PU/FPU 时)。

悬空时、所有引脚：STATUS0/1和 HW_SW_CTRL

尊敬的 PF：

感谢您检查斜升电压。

7月23日、回到您的消息、我看到您说"SPI readaout 文件与编程文件匹配"。 但是、我在您共享的.txt 文件中看不到寄存器匹配的情况。 您能否说明一下、当您看到寄存器回读与所需配置匹配时以及何时不匹配？

此致、
Jennifer

Jennifer、您好！

刚刚通过 I2C 将配置刷写到 LMK 中、然后通过 I2C 运行、运行正常。
保持相同的 EEPROM 并以 SPI 模式引导确实会再次显示该错误。

因此、我可以假设编程的配置正常。