• 状态
  • 已锁定 已锁定
  • 个回复 7 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 426 次查看
  • 用户 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.

[参考译文] TPS65987D：I2C 总线不稳定。 这是 SMBbus 吗？

admin
Guru**** 1818760 points
Other Parts Discussed in Thread: TUSB8041A, TPS65987D
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1083482/tps65987d-i2c-bus-unstable-is-this-smbbus

部件号：TPS65987D
“线程”中讨论的其它部件：TUSB8041A，，测试

大家好，团队

我们的应用程序正在通过 I2C 配置 PD 控制器时遇到问题。

设备每次都无法通过 I2C 消息进行 ACK。 发送长数据包时会发生这种情况。 这种失败的时刻并不稳定。

在我们的 I2C 实施中，我们需要使用缓冲区，这些缓冲区会产生静态 I2C 总线的瞬间。 这种不稳定似乎与公交车上的静态时段和长度的数量有关。

I2C 总线应该能够处理无限静态周期，SMB 总线有超时。 我们可以在指定为 SMB 总线的 TUSB8041A 上重现此行为。 如果我们操纵 I2C 通信以减少“间隙”，稳定性将得到改善。 如果我们操纵 I2C 通信以延长间隙，稳定性将下降。

我们还尝试了其他方法来研究稳定性，如 I2C 速度，温度，交换板和加电顺序。 找不到与此相关的关系。

在 TRM 和数据表中，有一个位置显示数据是从 SMB 规范复制的。 此图中的内容在 I2C 和 SMB 中很常见。

您能否确认 TPS65987D 中实施了 SMBbus (I2C 超时)？

如果是，您对这些超时时间有任何规定吗？

此致，

标记

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

    更多信息：

    已连接的逻辑分析仪具有无限内存，而不是具有"数字时刻"的范围。 还可以更改驾驶开关以在消息块之间增加间隙。 现在我可以完美再现效果。 如果字节块之间的间隙为~20ms，PD 控制器将在某个时间返回一个 nack。 可以是间隔后的第一个字节，也可以是间隔中第一个字节的正常 ACK。 然后突然又回来了


    一些屏幕截图：

    (1)典型寄存器9写入，64字节(总共66写入字节)：

    • 由第一个块执行的启动条件
    • GAP (准备下一个块+创建一些结果记录)
    • 第二个块+创建一些日志记录
    • 停机条件


    当间隙<~20msec 全部正常时。

    (2)软件是在每条成功的消息后，间隙(抖动很大)增加1毫秒。

    (蓝色注释中的间隙，消息重复并增大间隙，直至'断开点')

    (3A)当间隔太大时，一段时间后不再提供 ACK：

    在这种情况下，16.15毫秒的总线空闲时间是正常的，18.03毫秒会导致“延迟”故障

    (3B)正常结束。有效负载中的每个字节都有第一个半字节作为递增数。 第二个半字节始终为0101 (0x05)，因此可以更轻松地验证 ACK。

    (3C)但是，在间隔足够长后，突然不再提供 ACK。 即使在许多字节后 ACK 也不能正常工作。 这是以上突发事件：

    (4)更典型的(和预期的)故障(如果确实存在 SMBbus 而不是 I2C)就是这种情况。 在这种情况下，怠速间隙更长：

    整条消息：

    最后一个数据包，第一个字节失败：

    黑箱行为猜测：

    看来：

    • 总线确实有 SMBbus 行为
    • 空闲检测超时为16~18毫秒
    • 总线实际释放前大约需要~6毫秒(禁用 SDA 低 FET)
    • 超时功能与数据通信分开。 因此，上述“延迟时间”，总线工作正常。 在这段时间后，巴士停止运行，因为没有出现重新启动

    (5)死时间

    开放式问题：

    是否有人可以证实上述猜测，或提供有关这种不稳定的任何其他信息？

    (注：在 PTCH 模式下未配置的设备出现这种情况，配置失败。 未通过配置的设备验证)

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

    标记，

    我们的 PD 控制器都没有实施完整的 SMBbus 行为，但它们确实实施 了时钟延伸，以允许更高优先级的任务完成或实现总线转换。  我们将在不同的命令中保持 SCL 在不同的时间段内保持较低水平，以支持内部计时。

    如果设备处于 PTCH 模式，则设备所期望的唯一流量是与 PBMx 流相关的命令和数据，因此任何其他流量都可能会导致问题。

     这一过程是否发生在 PBMx 流程中？

    您的超时设置为什么？

    您的逻辑分析器似乎是一个 Saleaa。   如果是这种情况，您能否发布故障流量的.Sal 文件。  这将使我更容易了解正在发生的情况。

    此致，

    卡盘

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

    你好，查克，

    第一段以一个奇怪的句子开头，但我希望你说的是 PD 控制器已经实现了一些 SMBbus 功能。 因此，它不是严格意义上的 I2C (NXP UM10204规范)，也不是严格意义上的 SMBbus。 将 SCL 保持在较低的时钟拉伸状态是有效的 I2C 行为，但这并不是导致任何问题的原因。 这里的问题是没有来自 PD 控制器的 ACK。

    设备处于 PTCH 模式，我不知道您对 PBMx 流的理解。 TRM (SLVUBH2B)中未提及这一点。 但是，我尝试了几个以类似方式失败的随机 I2C 批量写入，当我尽可能限制间隙大小时，可以写入~150字节。 由于存在差距，这些情况似乎仍然失败，因为我无法完全控制这些差距。 在这种情况下，我将测试集减少为寄存器0x09的有效写入命令。 因此，我认为这应该解决更高级别的流量问题吗？

    我不知道这种超时的情况。 我假设您是指寄存器0x27，位14:12。 设备没有连接 EEPROM，并且只有 POR，因此我认为0x27的值仍然为0 (现在不在实验室)。 TRM 中的表格显示50毫秒为默认值，25毫秒为 POR 值.... 但25毫秒似乎在同一个球场。 该功能未被描述为未来，但从我的实验中，“超时”检测为~18ms，“超时+激活”确实为~25ms。 这种气味和我所遇到的问题非常重。

    当我回到实验室时，我会尝试使用其他一些设置。 我希望我遇到的问题会改变此设置的计时行为。 在这种情况下，我们可以确认 PD 控制器有类似 SMBbus 的行为，并且我们没有遇到一些被误解的问题，在我们修改 I2C 驱动程序时，这些问题会在以后再次出现。 对我们来说，进一步的改进将是尽可能地将时间安排在最长的时间内。

    作为一个附带的注意事项，对于该帖子的其他读者，纯 I2C 行为将不会有任何时间。 如果这是一个选项，那就更好了，同时在文档中明确指出，这不是真正的 I2C，但有一段时间。 此时，它在数据表中表示从 I2C 的最小速度为0kHz，即 DC，这意味着不会超时... 没有超时功能在 I2C 通信上具有重要优势，需要缓冲或多任务 MCU。 它还允许调试软件，因为可以使用断点而不会损坏持续的 I2C 通信。 很明显，TI 为什么在实施这些产品时会超时。 由于任何人都可能拉低 SDA 或 SCL，因此当 SCL 被一些行为不当的设备卡在低位时，没有总线恢复机制。

    使用的分析仪确实是一种有益的方法，但我找不到发布此文件的方法。 我只能从表单发布图像或这样的图像。 此文件被拒绝。

    迄今为止，我将在检查 I2C 超时设置后向您提供最新信息。

    标记

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

    标记，

    我所说的时钟拉伸是在 NXP UM 规范中定义的。  这是一项可选功能，但我没有看到 MCU 无法正常工作。

    如果您没有闪存或 EEPROM，则您正在使用我们所称的 PBMx 流来加载补丁并配置设备。

    您应该能够附加.Sal 文件，方法是单击编辑窗口底部的“插入”按钮，选择“图像/视频/文件”选项并附加文件。  一旦我有了该文件，我就可以快速调试此问题。

    此致，

    卡盘

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

    你好，查克，

    在这种情况下，我们正在使用 PBMx 流。

    我尝试上传文件但失败(已在我的原始帖子中尝试)。 当将其放入 zip 文件时，它会上传。

    该文件包含3个单独的测试，在这些测试中，我生成的消息在各块之间的延迟不断增加。 当我想起 一个小问题时，我停下来。

    总线上的第二个停止条件是我强制主端作为恢复机制，这是我对任何 I2C 错误所做的，因为我不确定 I2C 通信在哪个点停止。 这可以忽略。

    我在欧盟工作，因此在~ 12小时后，我将回到实验室测试 I2C 超时，但我非常确信这是根本原因/解决方案。

    e2e.ti.com/.../TPS65987-I2C-SMBbus-like-fail.zip

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

    你好，查克，

    已确认原因并找到解决方案！

    简而言之，我的黑框假设似乎是正确的。 I2C 超时。 这可以更改到1秒，因此在实际情况下这不会是问题。

    启动配置前写入以下数据将超时设置为150msec：

    I2C.WriteRepRead (0x23，//[U8] Device_address)
     ｛0x27，0x0E，0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x50｝，//[U8-1D] Write_data
     0)；//[I32] read_count

    但是有一些需要注意的事项...

    (1)数据表中提到 I2C 0 kHz 操作，IMHO 结果显示这是错误的，应该注意有超时。

    (2)超时并非纯粹。 它检测到超时时间~6毫秒，比设置的超时时间短，然后等待6毫秒后启动。 在这段死胡同里，I2C 正在正常响应，这使得很难发现这是一个超时的现象

    (3)未配置设备时(PBMx 流？) 寄存器0x27返回“无数据”，表示它不存在。 但是，它可以写入，I2C 超时正在正常运行

    深入了解我的实验和结果(请参阅随附的 zip 文件)：

    第一个基线(与以前一样增加块间的间隙)在~20msec 后仍然无法正常工作)设备未配置-6次尝试(在 POR 之后)。Sal

    当设备处于未配置模式时读取/设置/写入寄存器0x27时，读取寄存器0x27返回长度0x00 设备未配置-设置 I2C 超时1秒(读写-读0x27).Sal

    现在，I2C 超时设置为1秒，设备工作正常，间隙高达1秒设备未配置-多次尝试(I2C 超时1秒)。Sal

    将超时更改为150msec 会导致在设备未配置时失败-设置 I2C 超时150msec (写入)。Sal 设备未配置- 2次尝试(I2C 超时150msec)。Sal

    Protoworkbench:

    -使用配置命令记录150msec：将 I2C 配置为150msec - log.txt

    －未配置的内存转储设备：内存转储－unconfigured.txt

    设备配置现在工作正常，I2C 仍工作正常设备配置 I2C 超时1秒.Sal

    因此，感谢您的支持。 设置 I2C 超时正在为我们带来成功。

    (我会让您敞开脚步，让您结束工作，并代表您做一些最后记录)

    此致，

    标记

    e2e.ti.com/.../2022_2D00_03_2D00_11-I2C-timeout-setting-experiments.zip

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

    标记，  

    我将在下周初审查这些调查结果，并将调查结果反馈给您。

    此致，

    卡盘