[参考译文] LM9.8725万：使用LM9.8725万的死帧

您好Inaki：

感谢您的提问。 我将联系负责此设备的应用工程师。

您好，

很抱歉回复太晚，我正在调查您的情况，我会尽快告知您我的建议。

此致，

Costin   

您好Inaki：

如果我理解正确，您在系统的2 % 中遇到此问题。 对于您系统的2 % ，硬件重置后问题不会消失，但在软件重置并重新加载寄存器后问题会消失，对吗？

当您遇到故障状态时，是否可以重新读取寄存器？ 您读回的值是否与您写的值匹配？ 如果任何值发生变化，则可能提示问题发生的位置。

您能否执行几次ABA换用以帮助确定问题出在主板，设备还是位置？ 首先，在出现此问题的主板上，您能否互换两个芯片并重新测试？ 问题出在芯片还是位置？ 其次，您是否可以将故障位置的IC更换为已知正常工作的主板？ 另外，请将已知正常工作的IC放在故障板上以帮助关联。

您好，James：

我们测试的所有10个原型系统在大约2 % 的设备启动情况下都进入"死帧"故障状态，即如果我们重新启动任何设备100次，则无论我们使用哪一个系统，我们平均将出现2次故障状态。 一旦处于此状态，所有生成的帧中大约有10 20 % 以看似随机的顺序死机(请参阅第一个接线柱中的示波器图)，而其余的都是正确的，但这仅发生在AFE #2中。

如果我读取故障状态下的寄存器，则故障AFE (AFE #2)中唯一不同的寄存器是与PGA增益以及模拟和数字偏移相关的寄存器，差异很小。 在AFE #1中，相同的寄存器也不同(工作正常)。 如果我重新发送AFE #2处于工作状态的值，问题仍然存在(除非我重置状态机器和寄存器)。

一旦处于故障状态，返回工作状态的唯一方法是重置整个系统(关闭/打开电源)或重置状态机器和寄存器的AFE软件。

谢谢你。
此致，

Iñaki Lujambio

您好Costin：

我们测试了所有10个原型设备，它们的表现都是一样的，所以如果我们按照您的建议交换AFE，我们当然也会在新AFE #2中得到相同的故障状态。
换言之，这有力地证明它不是单个AFE芯片的故障，而是一个系统性问题，其性质尚不明确。

确切地说，第二个AFE不向CCD提供控制信号，它仅用于采样和AD转换。
但是，由于两个AFE都从外部源获得完全相同的ADC时钟(没有PLL以尽量减少计时问题)， 如果我们还假设存在与ADC相关的某些单独(但恒定，几ns) AFE组件时序差异，则可以通过采样微调设置(锁模时间和采样时间)来补偿这种差异。
首先，此问题不应导致~10 20 % 死帧，而是导致帧形状不良的100 % (由于时间错误，它要么坏要么好，但没有抖动)。
此外，我们尝试通过修改微调来调整采样时间，但对死帧没有任何影响(当然，好帧根据新的采样定时设置进行更改和移动)。

下图显示了我们系统的结构图：

谢谢你。
此致，

Iñaki Lujambio

您好Inaki：

同意您的所有意见，但我仍怀疑存在时间问题。
是否可以探测AFE的时钟输入，控制信号并进行抖动比较？
正如您所提到的，由于它只是2 % ，这不是延迟问题。

此致，
Costin

您好，Costin：

在深入研究了两个AFE的控制信号后，我们得出结论，问题不是来自案例2 % 中的AFE 2，而是来自案例1 % 中的每个AFE。 它看起来好像只有AFE #2有故障(并且错误地暗示其不同的电子环境可能有特殊之处)，因为在我们的设置中，死帧总是出现在AFE #2上。

换言 之，这似乎是每个AFE芯片都有的一个系统问题，在执行完全重置(关机/开机或状态机+完全寄存器重置)时，出现n ü~1 % 的机会。

问题在于，当处于故障状态时，SH请求和SH间隔之间的时间在所有情况下都不再是恒定的，并且在所有帧(SH_R-***)的大约10 % ... 20 % 中突然出现~20ns延迟。

我们总是假设问题出在AFE #2，但这只是因为AFE #1是向CCD模块提供控制信号的组件，因此其自身的采样始终是正确的，无论它是否延迟。 然后，其他AFE #2信号有时出现在较早(AFE #1故障状态)或较晚(AFE #2故障状态)，这会导致AFE #2在错误的时间采样，从而导致AFE #2输出上出现"死帧"现象。

下图显示了AFE #1和AFE #2在工作状态下的SH (SH1输出)和RS信号，其中：
－黄色：1号AFE的sh
－绿色：AFE #1的RS
蓝色：2号AFE的sh
－红色：AFE #2的RS

在这种情况下，所有SH和RS信号在1到2 ns内完全一致地对齐，因此在两个AFE中采样始终正确，如下所示：

在下图中，我们可以看到AFE #1有时相对于AFE #2延迟的状态(抖动似乎出现在AFE #2中，原因很简单，因为示波器的触发器位于AFE #1的SH中)，

因此，采样信号不匹配：

相反，下图显示了相对于AFE #1，AFE #2有时是如何延迟的。

两个AFE获得完全相同的SH请求信号，结果是其中一个AFE在案例的1 % (系统重置或AFE完全软件重置后)中有时会(在SH请求脉冲的10 % ... 20 % 周围)产生大约~20 ns延迟的SH间隔 (几乎是像素周期的一半)，导致CCD数据采样错误。

我们还使用20.000 测试周期运行自动测试设置，通过信号完整性检查执行重置，并且2.1 % 完全处于故障状态(即 每个AFE的1.05 %)。

因此，AFE芯片内似乎存在一些一般和系统的情况，在启动案例的1 % 中，这会导致这种延迟突然，偶尔发生，直到下一次完全重置。 这也表明除了设备启动时的"init - check - reinit - check"循环之外没有其他修复方法...

您对此有何想法？

非常感谢。
此致，

Iñaki Lujambio

您好Inaki：

在我看来，内部PLL在重置后不稳定。 系统是否在发送软重置前等待50mS？
我指的是数据表第84页注意：
"在启动或停止INCLK之后，或在软件重置之后(注册第0页，地址
1，[4：3])，用户应等待50毫秒，以使内部PLL和逻辑在之前稳定下来
正在恢复串行接口通信。"
根据图片，SH间隔已损坏，在工作台上正常运行时，尚未报告此问题。 我认为唯一可能发生这种情况的方法是使用一个不稳定的PLL

谢谢！
Costin

您好Costin：
是的，在启动INCLK并在软件重置后，我们会暂停100毫秒。 您的基准测试中可能没有报告任何问题，因为向CCD提供控制信号和采样的单个设备即使在SH间隔内存在抖动，也不会显示任何问题。
SH_R与SH间隔开始之间的时间间隔是否应为每种设计的设备常数？ 除了PLL之外，还有什么可能对该延时产生影响？ 您能想到任何可能对其产生影响的寄存器设置吗？

谢谢！
Iñaki Lujambio

您好Inaki：

由于PLL和逻辑稳定(100mS已足够)且MCLK和SH_R相同，我不理解为什么SH和RS不稳定。
正如你所说的，不稳定是半钟。 请将注册设置通过电子邮件发送给我：
costin.cazana@ti.com

谢谢！
Costin

您好，

将像素时钟更改为值的一半(从21.6 MHz降至~10MHz)也导致抖动时间是时间的两倍(从~20ns -->~40ns)。  这意味着抖动似乎等于一个INCLK周期(INCLK = ADCCLK =2*PIXCLK)。 因此，正如Costin在上一篇文章中所说的，半个像素周期。

此外，我们测试了死帧(抖动)现象也可能由INCLK更改事件(无任何重置等)引起。 为此，我们运行了一个测试系列，包括在21.6 MHz和~10 MHz之间连续更改PIXCLK的1万次。 令人惊讶的是，我们发现抖动状态只出现在~1 % 的情况中(即在两个AFE上)，这种情况专用于更改为更高的21.6 MHz时钟，而不适用于更改为10 MHz时钟。 在21.6 MHz和13.5 MHz之间更改PIXCLK时也发生了同样的情况，但当我们测试21.6 MHz-18 MHz的更改时，抖动状态出现在案例的2 % 上，当更改为18 MHz时，案例的~50 % 显示；当更改为21.6 MHz时，案例的~50 % 显示。  当我们使用较高的CCD时钟时，抖动似乎会出现。

此致，

Iñaki Lujambio