[参考译文] LMX2492：LMX2492的软复位偶尔失败

尊敬的 Christian：

复位会将所有寄存器复位为器件默认值、即 POR 值、如数据表中的寄存器映射部分所示。 如果复位成功、MUXout_MUX 将复位为"输出回读"、而 MUXout_PIN 将复位为"三态"。

复位后、我们必须对所有寄存器进行一次写入、以使其按需要运行。  

由于您向 R2写入0x004、您将要求芯片复位和断电。 我想芯片掉电了、但复位被忽略了。 因此、当您再次为其加电时、您仍然会获得所需的 MUXout 信号。

Noel、您好！

感谢您的回复。

当通过将值5写入寄存器0x02进行复位时、即在不断电的情况下复位时、我们确实会看到同样的问题。

每次尝试复位后、我们都会重新写入所有寄存器、包括与 MUXout 相关的寄存器。

我希望、未记录的寄存器 46..55 (0x2e.0x37)显然异常的状态可以为您提供提示？ 它们在"失败"状态下读取所有零、但在按预期运行时读取其他值。

此致、Christian。

尊敬的 Christian：

"当通过将值5写入寄存器0x02进行复位时、即在不断电的情况下复位时、我们确实会看到同样的问题。

每次尝试复位后、我们都会重新写入所有寄存器、包括与 MUXout 相关的寄存器。"

复位并重新写入所有寄存器后、您是否锁定了它？ 如果它被锁定、我看不到为什么您没有从 MUXout 引脚获得正确的输出。

Noel、您好！

是的、它在"失败"复位实例后处于锁定状态。 也就是说、Output_DLD 和 output_CPMON_Good 信号为高电平。 也就是说、我们通过同一个多路复用器观察它们、该多路复用器在设置为 Output_N_Divide_by 4时为我们提供恒定高电平。 但是、我们对 CPout 引脚的监控也表明它已锁定。

此致、Christian。

尊敬的 Christian：

好的、您确认它已锁定、这意味着您能够对器件进行编程、因此 SPI 逻辑没有任何问题。

是否可以尝试将 MUXout_MUX 设置为 GND 和输出 R/4？

Noel、

感谢您的支持。 我目前并不总是能够访问器件或实验室环境、因此我的终端会延迟

当器件在复位后进入我称为"失败"的状态时：

MUXout_MUX 设置为 N/4、MUXOUT 引脚处于恒定高电平(在正常条件下大约为25MHz)。

然后、我将 MUXout_MUX 设置为 R/4、MUXOUT 引脚 变为恒定低电平。

然后、我将 MUXout_MUX 设置回 N/4、MUXOUT 引脚 恢复为恒定高电平。

然后、我将 MUXout_MUX 设置为 GND、MUXOUT 引脚 变为恒定低电平。

然后、我再次复位器件、(在大多数情况下、除非连续失败两次)我看到 MUXOUT 处的预期频率。

OSCin 输入由 LVDS TCXO 驱动。 下面是 OSCin 输入的示波器图(注意100mV/分频)。 我们是否满足 LMX2492的输入要求？

您好、Christian、

如果我们能够在"失败"状态下获得完全回读结果、而回读结果在正常状态下作为文件(因此我们可以观察哪些特定寄存器和其他函数未正确复位)、那将会对我们有所帮助。 您能给我们这样做吗？这样我们就可以对状态进行比较了吗？ 它可能会为我们提供有关正在发生的事情的线索。

我没有看到 OSCin 有任何问题。

此致、

e2e.ti.com/.../lmx2492_2D00_allregs_2D00_good.txt

e2e.ti.com/.../lmx2492_2D00_allregs_2D00_fail.txt

尊敬的 Derek：

请找到上述两个文件。

注意：与 2021年1月26日的答复不同、CPMON_Good 似乎不是处于故障状态的"1"。 我认为这是可以预料的、因为我现在在系统复位后循环执行 LMX2492复位、而不是我之前使用的运行系统。 两种方法的故障率和模式是相同的。 我们的应用在 N/4输出端使用频率计数器、在故障状态下得到0、我通常使用该计数器来确定故障。  我在2021年2月12日的回复中还使用了范围、以确认出现故障时的 R/4和 N/4输出。 简而言之、我的假设或观察结果是、芯片是否"锁定"对于我们的问题无关紧要、即我们无法从内部多路复用器中获取分频频率。

尊敬的 Christian：

我相信在我们的某些器件上、相位检测器监视器有一个分频器复位设置、通常不公开并保留用于测试目的或在初始化期间进行简要保留。 在一个成功的 POR 或寄存器复位后、这个条件应该被清除、但是很明显、在某些边沿情况或者边缘时序中、复位失败。 我仍在浏览这些寄存器、但我们有关未公开字段的文档会与其他团队成员来回传递一些内容；我将告诉您我发现的内容、希望今天稍后能了解。

此致、

尊敬的 Christian：

我已经确定、在良好/故障条件之间变化的大多数位是电荷泵和其他偏置 LDO 的修整位、 还有一个明显名为"EN_PFD"的位、该位未被置位、因此、如果在启动时这些位未被正确置位、MUXOUT PFD 时钟衍生产品会出现一些问题是有道理的。 我正在尝试找出设置 POR 计时器的内容、但我怀疑它要么是内置延迟、要么以某种方式源自 OSCin 时钟。 希望明天能有更多更新。

此致、

尊敬的 Christian：

我今天发现的一件事：R2[3]是一个未经披露的位、必须设置为0。 在内部、该位被描述为在复位事件后写入偏置/修整值的自动填充位、并且该位必须设置为0才能自动填充这些值。 如果该位设置为1、则这些位可能不会自动填充、这类似于您描述的结果、其中所有偏置/修整位都设置为真正寄存器默认值(零)。 该自动填充位紧邻软件复位位位位 R2[2]。  

您能否在执行软件复位时监视 SPI 总线、并在复位导致"失败"状态的情况下查找边际时序？ 具体而言、我们将寻找在发送复位位位位之前可以解释为"1"的任何内容。

此致、

Derek、

我提出了一个有趣的意见：

在原始设置中、我执行以下操作：

// pll_spi_write (reg、data)；
pll_spi_write (0x02、0x04)；
_delay_us (1)；
PLL_SPI_WRITE (0x02、0x01)；
_DELAY_ms (1)；
PLL_SPI_writeOtherRegs ()； 

=>我获得了之前观察到的故障率、略小于1%

如果我在 第一个事务中添加要设置的 R2[3]、即我将第2行替换为

PLL_SPI_WRITE (0x02、0x0c)； 

=>故障消失了！ 根据你的最新建议，我认为这与我们预期的情况相反。

但是、如果我在 第二个事务中添加要设置的 R2[3]、即写入数据0x09而不是0x01、则会得到相同的1%故障率。

当我避免在第一个事务中断电时、也没有区别。

我们使用 uC 硬件 SPI、信号看起来非常清晰。 我还使用所有相同的观察结果将时钟频率从~900kHz 降低到~100kHz。 在失败的情况下、我也看不到任何具体的事情、第一个也看不到第二个交易。 我相信我在前面的实验中已经表明、设置 MUXout_MUX 的事务也没有问题。

这些是将 0x01和 0x0c 写入 寄存器2的示波器图

尊敬的 Christian：

偏置/修整系数加载的触发器是从高电平转换为低电平的复位位位、因此我认为将寄存器显式设置为1、然后设置为0对防止 R2[3]发生某种噪声跳闸有一定意义。 虽然您提供了新发现的权变措施的范围图、但我不确定0x01写入是否对应于故障条件情况；范围图时间戳之间存在相当长的时间、但这不一定证明0x01写入来自故障条件。 除非我们能够在故障条件下看到0x01写入以最终排除 SPI 总线噪声的可能性、否则可能性仍然存在(尽管我确实认为不太可能)。

需要注意的一种可能性是：当触发复位条件时、器件电源电流可能会突然变化、这可能会影响复位条件下的电源电压。 我能否获得器件 LMX2492部分的原理图、包括电源轨和任何旁路电容器、铁氧体磁珠等？ 您可能还需要在"失败"条件的0x04和0x01写入期间测量电源轨、以查看电源在转换至复位条件期间是否短暂掉电。

您是否在多个器件或电路板上测试过复位问题？

此致、

尊敬的 Derek：

关于 示波器图/SPI：我只直观地检查了故障条件示波器图、我发送的示波器图不是故障。 我用更高的采样率等重复了这项工作、无法确认故障案例中是否存在任何明显的违规行为。 我将附加图、在每个图中、您可以看到我上面提到的两个事务、然后是其他寄存器的编程。 数据线路上有几个较小的干扰、可以看到更近的放大、但它们极小、并且在故障和正常条件下也是打开和关闭的。 此外、相关寄存器是否仅写入？ 否则、我们可能也在回读中看到了一些东西。

电源：我将附上原理图、感谢您查看。 到目前为止，我们所做的，没有任何明显的差别

• 将电源电压增加到数据表中的最大值3.45V
• 将铁氧体磁珠逐一短接、在封装顶部有一根短接线、持续施加一些灵活的压力。 当然不是最佳解决方案、但目前我们必须最大限度地减少电路板上的焊接。 我仍然相信铁氧体磁珠端子之间的电气连接良好。

故障率：这在我们的应用中是一个长期存在的偶发故障、我最近才能够将其追溯到 PLL 复位。 所以这个问题似乎是系统的。 我最近在两个不同的电路板上进行了实验、这两个电路板都显示了大约0.8%的复位失败率。

我想告诉大家、我们能够通过减少应用中 PLL 复位的数量、并在正确的时间检查复位故障来缓解这一问题。 问题可能出在我们的应用或器件本身、我目前正在考虑后者。  我很有兴趣通过这种方法来理解根本原因、并避免系统中存在一个可能以其他问题形式表现出来的边际参数。 但是如果我们必须评估我们应该不断投入的努力量-好的。

是否有办法在评估板上设置重复软复位测试？

Christian、

我重复了您描述的~1%复位故障率、使用相同的寄存器写入序列来关断和复位器件。 我还尝试了您修改的序列、并从序列中删除断电写入、但与您的结果不同、我仍然获得相同的~1%故障率。

为了确认、我在您的帖子中看到您尝试了以下内容：

PLL_SPI_WRITE (0x02、0x0c)；
_DELAY_us (1)；
PLL_SPI_WRITE (0x02、0x01)；
_delay_ms (1)；
pll_spi_writeOtherRegs ()； 

这样可以防止出现错误？

我们仍在寻找根本原因。 我不确定我们是否能够提供一个好的解决方法。

此致、

早上好、Derek、

是的，使用 PLL_SPI_WRITE (0x02、0x0c)时，我没有通过 MUXout 引脚读取 N/A [ PLL_SPI_WRITE (0x27、0x9A)]或 R/4 [ PLL_SPI_WRITE (0x27、0x8A)]失败。 上述代码中的延迟均为1毫秒。

我  目前有两个器件可用于确认这一点。

此致、Christian。

Christian、

看起来您正在取得一些进展。  需要注意的一点 是、您提到的读回错误的寄存器 R46、... R55包含一些 LDO 相关位、寄存器 R52[7]是 R 分频器复位、寄存器 R52[6]是 n 分频器复位。  我在原理图上也没有看到任何可疑的东西。

Dean