• 状态 TI Thinks Resolved
  • 个回复 14 个回复
  • 答案 3 答案
  • 名订阅用户 15 名订阅用户
  • 次查看 502 次查看
  • 用户 0 名在线用户
选项
选项
相关

TCAL9539-Q1: 访问此芯片I2C 挂死

ZIYANG LAI
Prodigy 205 points
Part Number: TCAL9539-Q1
Other Parts Discussed in Thread: TCA9517, TCAL9539

hi TI expert，

我们遇到一个偶发问题：

我们通过MCU 的I2C 连接了两个 TCAL9539-Q1，地址分别配置为（0x74 & 0X75）;

MCU上电后，对ioexpander 做配置 如下：

分别 对 0x74& 0x75的配置：0x02 写 0x0000——》0x06 写 0x00e0 ——》0x46 写0xFFFF——0x48 写 0x0000——》0x4A 写 0x0000 ； 配置结束后
异常波形如下，访问ioexpander 0x74后，ioexpander 回复 数据后，没有nack 导致回复0x0060 循环，最终把i2c bus 挂死：图二是正常波形，有正常的NACK。请问什么i情况回造成 故障波形？谢谢
  • 0
    TI__Mastermind 21245 points

    您好

    已经收到了您的案例，调查需要些时间，感谢您的耐心等待

  • 0
    TI__Genius 13665 points

    您好，

    第一个波形显示了发送器件地址0x74以及写入位到地址0x01处的输入端口寄存器1。 这将设置指针字节(命令字节)。 接下来是具有读取位的器件地址、然后是输入端口寄存器1中的数据、然后是输入端口寄存器0中的数据。

    第二个波形很难读出。 我们是否对问题有更清晰的了解并可以提供字节读数？

    0x74或0x75器件地址的第二个波形吗？ 问题是否仅在一台设备上出现？

  • 0 回复 Lydia
    Prodigy 205 points

    hi Lydia.

    第一个波形是异常的波形，读0x74 的0x01 寄存器，ioexpander 回复了0x6000+ack，导致 一直循环，最终I2C 总线被挂死了如下图：

    第二个波形是正常的波形，作为参考而已。 也是最后读了0x74的 0x01 寄存器，然后ioexpander 回复了0x60 的数据，+nack ，就结束了i2c通信，这是正常的。

    有多台设备 复现了，但单台复现的概率都较低。

  • 0 回复 ZIYANG LAI
    TI__Genius 13665 points

    您好，

    在 IO 扩展器的读取命令中、第9个时钟周期的 ACK/NACK 位由主机控制器提供。

    异常波形与正常波形的唯一区别是在异常波形中提供了 ACK、在正常波形中提供了 NACK。

    主机控制器负责停止数据读取流、否则 IO 扩展器会继续将读取的数据移位到 I2C 总线上、并继续接收来自主机控制器的 ACK。

    这听起来像是主机控制器读取数据的方式存在问题。 客户能否检查 ACK/NACK/STOP 位周期周围的软件？

  • 0 回复 Lydia
    Prodigy 205 points

    好的，我们看看MCU这边的情况，谢谢

  • 0 回复 Lydia
    Prodigy 205 points

    hi Lydia, 我们抓了一下波形，黄绿1.8V是靠近ioexpander 的波形，红蓝是靠近MCU 侧的波形，I2C 中间有贵司TCA9517DGKRQ1的电平转换芯片。 我们发现确实是MCU 在第九个时钟没有发NACK， 持续了400多cycle 后，最后是ioexpander 把 I2C总线的SDA拉低了，这是正常现象嘛?

  • 0 回复 ZIYANG LAI
    TI__Genius 13665 points

    您好，

    ZIYANG LAI 说：
    最后是ioexpander 把 I2C总线的SDA拉低了，这是正常现象嘛?

    客户是否在这里说I/O扩展器将SDA拉低至ACK总线？ 如果I/O扩展器收到正确的I2C命令，则这是正常现象。

    从上面给出的波形来看，我看不到任何问题... 客户是否达成了解决方案？

    顺便说一句，蓝色波形上的VOL变化是TCA9517缓冲器偏移电压与在ACK脉冲(第9时钟周期)期间总线B侧拉低的器件相比的结果。

  • 0 回复 Lydia
    Prodigy 205 points

    lydia

    这个波形明显不对啊，为什么ioexander 在最后 把I2C总线的SDA 拉低（蓝线）？这会把I2C 总线挂死的呢。

  • 0 回复 ZIYANG LAI
    TI__Genius 13665 points

    您好，

    TCA9517似乎正在从A侧驱动低电压，VOLB =~0.52V，并且来自MCU的A侧输入保持低电压？ 

    I/O扩展器在VOL大大低于0.52V的B侧每第9个时钟周期对总线进行确认。

    如果我的理解是正确的，则挂机是由于设备位于A侧？

  • 0 回复 Lydia
    Prodigy 205 points

    Lydia,

    对，MCU 在 B侧(3.3V，红蓝波形)， 诚然故障是由于 read 操作，MCU在 read 完后第9 个时钟没有发出NACK，导致访问一直循环。 但是截图里，到了最后一次的时候，MCU在read 操作的第九个时钟也是发出了ACK， 但是 随后被A侧的ioexpander 拉低了（因为蓝色SDA电平约0.5V），我现在的疑问是，问什么ioexpander 要在这一次把SDA拉低，这样会导致I2C 总线挂死

  • 0 回复 ZIYANG LAI
    TI__Genius 13665 points

    您好，

    ZIYANG LAI 说：
    对，MCU 在 B侧(3.3V，红蓝波形)， 诚然故障是由于 read 操作

    目前我的理解是 TCAL9539位于 TCA9517缓冲器的 A 侧。

    MCU 位于3.3V 侧、即 TCA9517缓冲器的 B 侧。

    I/O 扩展器从 A 侧到 B 侧提供读取数据。 因此、我们看到静态电压偏移~500mV VolB。

    当 MCU ACK 拉至低于该值、以便将 ACK 发送回 I/O 扩展器。

    我向客户提出的问题是、对于最终的读取事务、MCU 能否向 I/O 扩展器发出 NACK 而不是 ACK、以向目标器件指示它已完成从扩展器读取数据？ 发出 NACK、然后发出停止条件、以查看这是否可解决问题。

    否则、提供 ACK 似乎会向 I/O 扩展器指示它正在等待读取另一个字节。

  • 0 回复 Lydia
    Prodigy 205 points

    hi Lydia

    对于MCU 没有 发出NACK ，我们在内部调查。我这里的疑问是，最后一次，MCU 在 第九个时钟发出的是 ACK ，但 最后一个cycle，ioexpander 把 SDA 拉低了这个问题。即下图 绿圈和绿色箭头的地方，显然蓝色SDA 一直被拉低，且电平约为0.5V，为A侧即ioexpander 拉低的，这是为何？谢谢

  • 0 回复 ZIYANG LAI
    TI__Genius 13665 points

    您好，

    我不太清楚为什么它在ACK脉冲后保持低位。 我试图在前面的回应中描述这一点，因为这里MCU正在确认总线，告知IO扩展器它已准备好进入下一个字节。 由于MCU没有给出一个信号，I/O扩展器期望SCL上有一个时钟，因此它可以开始将数据移回MCU。 但是，现在MCU时钟变为空闲状态，但I/O扩展器试图从其输入端口寄存器中提供数据的MSB，但由于SCL上没有发生时钟，因此它在SDA上保持低电平。

    要解决这一问题，如果MCU要停止从I/O扩展器读取数据，它应该给出一个nack而不是ACK，以便它可以与I/O扩展器进行通信，因为它已经从I/O扩展器接收数据。 否则，I/O扩展器将继续认为它应该无限期地将数据反馈给MCU。

  • 0 回复 Lydia
    Prodigy 205 points

    明白，谢谢

x 出现错误。请重试或与管理员联系。