[参考译文] DS90UB954-Q1：DS90UB954-Q1至DS90UB953-Q1 BCC I2C错误

您好，David：

我尝试总结到目前为止发布的所有信息。 整个系统似乎是：

传感器-> 953 -> 954 -> ISP

ISP能够直接向954发送I2C命令，没有任何问题，但您在从ISP向远程传感器发送I2C写入命令时遇到问题。

1. 您能否确认可以从ISP向953设备发送读/写I2C命令？
2. 953和954设备之间是否有稳定的锁？
   1. 您可以通过多次读取954中的寄存器0x4D来检查此情况，每次读取之间有几秒钟的延迟。 如果锁定状态已更改，LOG_STS_CHG寄存器位(0x4D[4])将设置为1。 读取时清除此寄存器位。 如果您可以多次读取此寄存器，并且它始终为0，而LOG_STS (0x4D[0])始终为1，则您可以确认锁定是稳定的。
   2. 我想检查当通过电缆从953>954发送ACK时是否可能丢失。

最佳，

Justin Phan

Justin，您好！

不，您说的不正确。
也许我之前的帖子不清楚。  
我将再次使用相同的范围捕获，但要更详细一点。   

底部的三个轨迹(紫色，绿色，I2C_Snsr)是953和传感器之间的I2C信号。
前三条轨迹(黑色，水，I2C_ISP)是ISP和954之间的I2C信号。

您可以看到，第一组4字节由{ 7位地址+写入位，16位寄存器偏移，8位数据要写入}组成。  在所有情况下，您都可以看到953和传感器之间的9时钟的数据信号偏低。  这是传感器产生的有效堆叠至953。  您还可以看到954将该ACK发回给ISP。   

在下一个写入周期开始时，第一个字节是地址0x34 (与之前的地址相同)，未完成.... 但953和传感器之间的此字节存在ack "is (是)"。  因此，传感器"确认"地址字节，953确实提供了捕获它的时钟，但有两种情况：1)该确认未从953和同轴电缆中确定，或2) 954确实收到了它，但未将它提供给ISP。

另外，如果你看一下我在第一篇文章中提到的波形捕获，你会发现954保持时钟信号低150毫秒，这是BCC信道看门狗超时值。  所以，问题是在953和954之间，或者在954本身。

回答您的问题：
1)写入"DO (执行)"使其进入传感器寄存器。
2)锁定和通过都是稳定的。
3)是的，ack可能在同轴电缆上丢失，但我们"不"丢失锁定信号。

谢谢！
David

您好，David：

感谢您的澄清。

您似乎能够对远程传感器执行一次I2C写入，但发送到传感器的下一次I2C写入失败。 示波器屏幕截图显示目标传感器在第二个写入周期中确实产生ACK响应，但由于某种原因，ACK不会出现在954/ISP I2C总线上。 由于ACK不出现在954/ISP I2C总线上，BCC监视器计时器在大约254毫秒后取消I2C事务。

1. 能否提供954 (寄存器0x4D - 0x4E)上RX端口错误寄存器的寄存器转储？
   1. 如果953通过电缆链路将ACK发送到95.4954万将在其I2C总线上重新生成信号。
   2. 我要确保通过转发通道(SER->DES)发送的数据中没有数据损坏。 954应该能够通过寄存器中的错误标志检测其接收到的任何数据是否损坏。
2. 是否也可以在ALP程序中运行MAP工具以检查信道链路质量？
   1. https://www.ti.com/lit/ug/snlu243/snlu243.pdf?ts=1652830375918&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDS90UB960-Q1 
3. 954 I2C总线上是否有任何其他组件(除ISP外)可能被怀疑是问题？
   1. 例如，可以调查的任何I2C缓冲器，扩展器或其他主/从设备？
4. 954板上I2C总线的I2C上拉电阻器是什么？
   
   1. 上拉电阻值是否与最佳上拉电阻值匹配？ 可使用此应用程序计算最佳I2C上拉电阻器注：
   2. https://www.ti.com/lit/an/slva689/slva689.pdf?ts=1652830114314 

最佳，

Justin Phan

Justin，

1)故障非常罕见且非常随机，但如果/当我捕获一个寄存器集时，我可以转储这两个寄存器集。
  a)这个想法(我们已经尝试过)的问题是，由于寄存器是在启动过程中，因此在感兴趣的点没有意义。  首先设置SerDes寄存器，然后设置传感器寄存器。  这意味着传感器的视频输出不稳定，在我们关注的时候，肯定会在SerDes路径中产生错误。
  b)是的，我知道。
  C)可以理解，但在引导过程中寄存器转储并不是真正的信息。
   i)在中断服务例程中，我们首先要做的是读取寄存器，以便清除引导过程中发生的任何无意义的错误。
  d)我们不会失去锁定，这是我们在此期间拥有的最重要的数据点。

2)我无法运行地图工具，但我已多次手动测量数据，并且我们运行的频率显示了清晰的图案。  

3)有两个I2C主控器可以访问954 I2C总线。
  A) ISP直接连接到954 I2C引脚。
  B)有一个I2C 4通道开关，它也有一个输出，直接连接到954 I2C引脚。
  C) Nvidia tx2主控I2C交换机的输入端。
  d) tx2仅在启动过程开始时通过I2C开关访问954。
   i) tx2控制着ISP重置线路，并在使ISP退出重置之前对SerDes部件执行其所有I2C配置。
   ii)一旦ISP停止复位，tx2就根本无法访问交换机。

4)我理解您关于下拉值的问题，但您有示波器捕获，您可以看到SCL和sda转换看起来不错。  
  a)值为4.7K
  B)此外，如果这只是一个上拉问题，您会在I2C总线上看到某种类型的"突起"信号。  您看不到这一点。  从信号完整性的角度来看，总线实际上运行良好，我们知道SCL为什么不运行(954使其保持低电平)。  我们还知道sda过高的原因(954或ISP都不是驱动它的，因此它被拉起)。

谢谢！
David

Justin，  
我认为954号线在整个看门狗超时期间保持在低位，迫使我们认为"等待ack/nack的逻辑也从未收到过"。  如果它获得了攻击，则应该将sda拉低并释放SCL。  如果它得到了一个nack，它会同时释放SCL和sda，这会产生一个nack。  它超时，因为它"无应答"。  954逻辑似乎没有被锁定，因为在超时时，它会正确释放SCL和sda，从而产生nack。   

我认为，上述情况使我们想更仔细地研究以下问题：

1)我们如何确认953 "Did (是否)"捕获了攻击？
  a)我们是否可以说这是成功的，因为：
    i)传感器保持sda过低，不会干扰SCL信号循环。
   ii) 953确实发布了SCL，捕获显示了在一个良好位置采集数据的上升沿。
2)我们如何确认953 "Did (是否)"存储从总线捕获的ack数据？
3)对于返回的ack/nack位，转发(953至954)控制数据包是什么样子的。
4)转发通道控制数据包是否随高速数据一起移动，还是仍以BCC 50MHz移动？
5)我们能否监控Rx0端口上输入的控制数据？
6) I2C数据如何从Rx0端口移动到954 I2C逻辑寄存器，我们是否有任何方法可以查看寄存器中的值？
7)当BCC通道监视程序超时时时，是否有任何与它关联的寄存器给出了超时的明确原因？

谢谢！
David

您好，David：

我发布的问题是为了帮助我更好地了解您的系统，并看看我是否可以缩小系统中可能存在问题的区域。

953设备应该没有问题。 953将以40位帧的形式连续发送视频数据，I2C数据，GPIO数据等。所有这些都通过Rin+/-引脚发送到连接的954。 954将获取帧中的I2C信息并在954本地I2C总线上再生。 没有寄存器位表明953正在正向通道帧中成功发送I2C位， 但是，只要 在953 I2C总线上满足I2C引脚的所有数据表规范，953应该不会在本地I2C总线上捕获数据。 953中的功能应该没有问题。  

953数据表中简要介绍了40位帧，但不能公开共享有关帧结构和内部设备结构的特定详细信息。

 我有两个主要怀疑领域。

1. 953和954正在失去锁，这将影响从953发送到954的数据。    如果您在运行系统一段时间后看到954上的LOG_STS_CHG寄存器设置为1，我怀疑953和954之间的链路质量有问题。
   
   1. I2C错误是否仅在启动时发生？ 或者，您是否知道在系统通电并运行后是否会发生这种情况？
   2. 我同意在初始化时来自传感器的视频数据会触发一些错误，但我主要关注指示链路质量的错误标志。  
   3. 如果没有可疑的转发信道错误，我们可以排除这种可能性。
2. 如果您能够确认953和954之间没有链路问题，我怀疑954 I2C总线上有干扰。
   1. 您是否可以移除954 I2C总线上的所有其他设备并只留下一个主设备，以查看I2C问题是否完全消失？

最佳，

Justin Phan

Justin，您好！

我理解。  我们都希望缩小可能性。  我相信我回答了你的问题。  如果我错过了一个，请告诉我。

我同意953“应该”以某种方式工作，但事实仍然是，我们有一个范围捕获，显示传感器提供了检测，953提供了捕获它的时钟，但检测不出现在954 I2C总线上。  所以，要么是在953中没有注册，没有将它放入40位数据包，在到达954时没有将它从40位数据包中取出， 或者没有按照954中的逻辑向ISP生成确认。  路径中的其中一个链接无法正常工作。  我毫不怀疑，这可能是由于某些东西超出规格或未正确编程，但确实发生了这种情况。   

如果有一些设置或未设置以显示已发生的攻击，我必须接受您的指示。 但是， 将SCL线保持在低位的954似乎表示逻辑仍在等待写入周期中的ack或nack的应答。  这是怎么发生的？  954决定如何生成一个应答，而不是返回ISP？

对您的"1"注释：
  我们没有失去锁定。  如果我们丢失了锁，我会从正在运行的代码中知道它。  我们不会失去锁定。
我不想说它只在启动时发生，但我从未见过它在任何其他时间发生。  
我不知道有任何转发信道信号完整性问题，但再次强调，这是您在修复之前永远不会排除的问题。

对您的“2”评论：
 I2C总线上唯一连接到954的另一个组件是I2C开关。  我无法删除它，因为这样做将不允许tx2配置954和953部件。  ....但是.... 你可以看到波形，从我们对I2C，954和ISP的认识中可以理解。  该总线上除了ISP和954外没有其他内容。

谢谢！
David

您好，David：

我最怀疑的是，信道链路上的数据正在损坏，这导致ACK位在发送到954之前丢失。 因为我们知道ACK出现在953端，而9553的行为是将ACK位发送到954端，但由于某种原因，它不显示。 然后，根据给定的信息，我最可能得出的结论是ACK位在传输过程中丢失。 这是比953无法捕获I2C总线中的单个ACK位更容易验证的原因。

锁定丢失是发生数据损坏的一个指标，但我需要知道完整的错误寄存器转储，以衡量系统中的情况并建议解决方案，因为错误寄存器将检测通道中发生的各种错误。

这涉及读取954中的寄存器0x4D-0x4E，甚至可能是953中寄存器0x52，0x55和0x56中存储的Back Channel错误。 如果检测到任何错误，我怀疑信道链路上的某件事正在影响数据，并导致此不常见的ACK位丢失。 可能ESD二极管正在起作用，或者PoC网络存在问题。

您能否先清除这些寄存器，然后在运行系统一段相当长的时间后提供寄存器转储？

由于总线上只有954和ISP，因此我们可以忽略另一个I2C本地主控引起问题的可能性。 我想重点调查渠道的完整性。

最佳，

Justin Phan