[参考译文] I2C 会卡住

将从器件在中间字节中停止是相当不寻常的。 在这种情况下,我已经诊断它(几乎)总是发生,因为主器件(无论出于何种原因)停止发送时钟。  

您似乎有这样一个事件的示波器跟踪；看到它会非常有用。

感谢您的回答。
是的、我使用逻辑分析仪轨迹图(.png)。 但我如何把它放在这个站点上呢？ "image/video"文件"不适用于本地文件系统(win10)。

我成功地做到了这一点(使用.png)、就在此时[Win11]。 单击"URL"框下的"upload"一词将显示"File Open"对话框。

抱歉、我忽略了这个词。

这是 SDA 为低电平时的布线。

这是具有低电平的迹线。 这可能是另一个问题。 它分为两部分。 它们有很大的时间间隔、但属于在一起。

是否可以读取？

感谢您的支持。

在第一个走线中(SDA 低电平)：似乎主器件已经停止发送时钟。 在第三个 Rx 字节结束的 ACK 之后、它不会使 SCL 为低电平以允许从器件接管、也不会尝试发出停止命令。  

在第二个/第三个迹线中(SCL 低电平)：非常长的中字节时钟延展是不常见的。 延展时钟的中间字节是合法的、但我不认为我以前这样做过。  

在我看来、如果您关闭 USCI 的输入时钟、有可能会发生下面的任一种情况。 您是否使用 LPM？ 你是否使用 SMCLKREQEN 位做了任何事情？

对于第一个迹线：Re《 UCBxRXBUF 读取用户指南》(文献编号：SLAU367P)第32.3.5.2.2节、借助于更真实的眼图、它会显示"如果没有被读取、那么主器件将在接收最后一个数据位期间一直挂起总线直到 UCBxRXBUF 被读取。" 我总是把这理解为"延长时钟"、但可能我没有仔细看、实际上这意味着它将时钟保持在高电平、以防止从器件呈现其下一位。

Wordsmithing arrow:有没有任何机会你的固件可以"忘记"读 RXBUF?

我没有写入在第一种情况(SDA=LOW)下、应该从从器件传输以下字节：0x13、0x22、0x45、…… 这些字节在测试中是恒定的。 看起来从器件停止发送第二个字节。 SMCLKREQEN 位为1、不会在固件中更改。 两个控制器的独立地址输入到 UCB0I2COA1中。 这些中断有中断例程：
USCI_I2C_UCALIFG
USCI_I2C_UCNACKIFG
USCI_I2C_UCSTTIFG
USCI_I2C_UCCLTOIFG
USCI_I2C_UCSTPIFG
USCI_I2C_UCRXIFG1
USCI_I2C_UCTXIFG1
USCI_I2C_UCRXIFG0
USCI_I2C_UCTXIFG0
当在主控模式下接收字节时、USCI_I2C_UCRXIFG0的例程被执行并且 UCB0RXBUF 被读取。 处理器以16 MHz (主器件)或24 MHz (从器件)运行。 不幸的是、要弄清在关键时刻是否阻止了中断处理、这并不容易。 您是否知道如何测试此项？

几乎可以肯定是您的代码出现了故障。 主器件、从器件、或两者兼而有之。 所以、如果没有看到该代码、任何人能做的最好的就是猜测。

我不确定禁用中断是否会有问题。 存在流控制(请参阅上面的 UG 报价)、因此在 再次启用中断后将继续执行。 但是、如果主器件丢失了跟踪(丢失了 RXIFG？) 并且永远不会再次读取 RXBUF、您可能会看到类似这种症状。

您该怎么做来响应 UCCLTOIFG？ 更一般地说:是否有任何情况下,你可能在交易期间应用 UCSWRST?

作为一个普遍的观点:逻辑分析仪通常光泽在小的异常上的导线,特别是噪声。 我在这些案例中看到大多数 SDA 卡在低电平状态下的总线噪声非常大(主器件看到过多的干扰并放弃)。 如果您有一个示波器、这可能是使用它的时候。

感谢您的分享。 我将使用示波器对此进行研究。 我已经看到、在代码中有人尝试用 UCSWRST 保存一些内容、然后进行重新初始化。 我将修改代码。 遗憾的是、在此展示一下已经很长一段时间了。 我又收到一个问题。 逻辑分析仪会在读取结束时显示 NACK、然后 SCL 和 SDA 同时变为低电平、然后变为高电平。 这是主器件读取操作的正确结束吗？

Unknown 说：

这是主控器读操作的正确结尾吗？

如果您了解 I2C 的工作方式、而不是取决于逻辑分析仪、这将会有所帮助。

当时钟按预期变为低电平时、数据线被拉至低电平以发送 ACK。 但该时钟周期由于某种原因被缩短了。 分析仪混淆。 时钟低电平时间应与之前的周期相同。 也许主器件被重置了。 这会解释缺少停止条件的原因。