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

[参考译文] TPS40400：I2C 在错误地址获取 ACK

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

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1125724/tps40400-i2c-getting-ack-at-wrong-address

器件型号：TPS40400
主题中讨论的其他器件： TMS320DM8168

大家好、

    我们在设计中使用 TPS40400为 TMS320DM8168处理器提供 AVS 内核电源。 使用电阻器将 TPS40400的地址编程为0x38 (八进制为70)。  TPS40400   通过 I2C 连接到 TMS 处理器。  当我们运行 I2C 探测命令以 列出总线中已连接的器件时、我们将在0x0C 时以及连接到 I2C 总线的从器件(包括0x38)获得确认。 我们的器件中没有地址为0x0c 的从器件。 我们发现 TPS40400确认0x0C。  即使我们多次使用 I2C 探针、这种情况也只会发生一次、有人能解释一下吗？ 。

下面、我将附加在0C 时器件通过数据0x70进行确认时捕获的图像。  

当我们断开 Tps40400与总线负极 ACK 的连接时、仅为0x0c

TPS40400_REMOVED

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

     

    TPS40400正在跟踪地址0x0C、因为它支持 SMBus 的警报响应地址(ARA)功能。  具有系统警报的器件将 ACK 警报响应地址(ARA、0x0C)并以其地址作为数据字节进行响应。  一旦它使用其地址做出响应、它将清除警报、这就是它只对地址0x0C 做出响应一次的原因

    如果您需要有关 SMBus 或 PMBus 的更多信息、请转至：

    http://www.smbus.org

    http://www.pmbus.org 

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

    非常感谢您的回答。

    1. 但根据 SMBus 规范。 仅当存在中断/故障时、器件才会响应0C。 那么、我们在0x0c 中得到的这种确认是否是  由于 IC 中的有效故障所致？ 。 我能否获得 IC 可生成的所有故障条件的列表？ 以便我可以检查器件生成的故障。
    2. 此外、器件以其地址作为数据进行响应、此处我们将 TPS 的地址设置为八进制70、表示十六进制38。 但 当我们探测时、传输的数据为0x70而不是0x38
  • 0
    TI__Guru**** 1135610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    响应地址位于位[7：1]位置、位0是读取/写入位、因此地址0x38将产生0x70或0x71的地址字节、具体取决于读取还是写入。

    读出 STATUS_BYTE (0x78)和 STATUS_WORD (0x79、两个字节)值以查看设置了哪些警告。

    然后、您可以检查关联的 STATUS_BYTE 以查看寄存器0x7A - 0x80中触发了哪些警告或故障、以了解具体详细信息。  该警告很可能出现在 STATUS_CML 中、即0x7E

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

    我们已检查 STATUS_BYTE、STATUS_WORD、发现问题出在 STATUS_CML (第6位显示无效/不受支持的数据)。 您是否知道这种情况的发生原因。 当我们多次测试时、此问题仅在一次情况下发生。

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

     

    当尝试写入只读命令值或尝试将数据写入其可编程范围之外的命令时、会标记无效或不受支持的数据。

    在读取可能会生成无效数据警告的地址0x0C 之前、检查您是否正在向器件发送任何其他命令/写入尝试。

    只发生一次、因为从警报响应地址读取会清除警报、直到生成新的警报。  一旦警报被清除、TPS40400就不再对地址0x0C 做出响应、直到它有一个新的警报。

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

    根据指令、我们已检查是否有任何写入尝试、但我们未找到任何写入。 下面、我将分享终端屏幕截图和我们从逻辑分析仪获得的输出。

    e2e.ti.com/.../logic_5F00_analyzer_5F00_op.txt

     因此、我们看到的问题似乎不是由非法写入尝试造成的。 因为这里不进行写入。 此外、我们还可以通过尝试写入只读寄存器来重新创建问题。 是否有任何其他原因可能导致同一问题？   

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

    我需要检查发出的其他通信可能触发无效数据。

    您是否多次运行此检测脚本？

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

    是的、但它不是脚本、我们在 U-boot 中多次运行命令"I2C probe"。

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

    您是否在第一次或第二次通过 U-boot 运行时看到此错误？

    PMBus 认为接收其地址的器件在事务开始时带有读取位、这是一个通信错误、这可能是导致无效数据标志的原因。  我可以检查。

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

    是的、我们在 U-boot 中的第二次运行时看到此错误。  

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

    您好，Vishnu，

    Peter 将在明天回复您。

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

     

    就是这样。  该例程使用接收字节、该字节会以器件地址开始传输、后跟一个读取位、这是符合 PMBus 标准的无效传输类型。  这将创建无效数据标志。

    您可以通过向 TPS40400器件发送"清除故障"来清除该标志。  清除故障是一个发送字节(器件地址+写入位、命令代码= 0x03、无数据字节)、用于清除 STATUS_CML 中的警告。

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

    我们在内核中使用 I2CDetect 对此进行了测试、但我们很少发现0C 确认。 您知道这在 u-boot 和内核中有何不同之处吗？ 在 U-boot 中、问题是在我们运行 i2c 探测器时第二次创建的、但在内核中、未找到。 我们并不是说问题不是由人造成的、而是有时仅出现。 此外、我们还探测了 SMBALERT#引脚、该引脚始终处于低电平状态。

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

     

    根命令中的-r 选项使用"Read Byte"协议而不是接收字节协议。

    接收字节发送地址+ Rd 并期望立即从器件返回数据。

    读取字节发送地址+ WR、后跟命令代码或 I2C 寄存器地址和重复起始地址、然后是地址+ Rd  

    先前的实例接收字节是 PMBus 事务错误

    主实例读取字节不是 PMBus 事务错误  

    如果您尝试运行 i2cdetect 而不使用内核中的-r 选项、我认为您会看到相同的问题。  如果您可以在 U-boot 中使用-r 选项运行 i2cdetect、则可能不会看到问题。