[参考译文] TM4C1294NCPDT：I2C 从忙状态恢复

您好、Yan、

 从器件将 SCL 保持为低电平的时间有多长？ 当您说主器件卡在忙状态时、SCL 保持低电平的持续时间是否重要？ 换言之、如果 SCL 在短时间内保持低电平、主器件是否会继续并且不会卡在忙状态？  

 您是否尝试过 CLTO (时钟低电平超时)？ 我将建议您始终启用此功能、以便进行正确的 I2C 设置。 您不希望从器件永远保持总线。 您应该提供一个机制、让主器件和总线在一个可编程超时周期后释放。 一旦总线超时、您将发出一个停止条件来恢复总线。 请参阅以下数据表摘录。  

18.3.1.6时钟低电平超时(CLTO)
I2C 从设备可以通过定期将时钟拉低来扩展传输、从而创建一个慢速位
传输速率。 I2C 模块具有一个12位可编程计数器、用于跟踪的时长
时钟保持低电平。 计数值的高8位可通过进行软件编程
I2C 主机时钟低电平超时计数寄存器(I2CMCLKOCNT)。 低四位不是
用户可见且为0x0。 在 I2CMCLKOCNT 寄存器中编程的 CNTL 值必须为
大于0x01。 应用程序可以将计数器的八个最高有效位编程到
反映交易中可接受的累计低电平周期。 计数在开始时加载
并在主器件内部总线时钟的每个下降沿进行倒计数。 请注意
为该计数器生成的内部总线时钟以编程的 I2C 速度持续运行
如果 SCL 在总线上保持低电平。 达到终端计数后、主状态机强制中止
在 SCL 和 SDA 释放时发出停止条件、从而在总线上产生中断。

例如、如果 I2C 模块以100kHz 的速度运行、则对 I2CMCLKOCNT 进行编程
寄存器更改为0xDA 将转换为值0xDA0、因为低四位设置为0x0。 这种情况
将转换为3488个时钟的十进制值或34.88ms 的累积时钟低电平周期
100 kHz。

时钟启用时、I2C 主机原始中断状态(I2CMRIS)寄存器中的 CLKRIS 位被置位
超时时间已到、允许主器件开始纠正措施以解决远程从器件问题
状态。 此外、I2C 主机控制/状态(I2CMCS)寄存器中的 CLKTO 位也会置位；该位也会置位
在发送停止条件或 I2C 主机复位期间清零。 原始 SDA 的状态
和 SCL 信号可由软件通过 I2C 主总线中的 SDA 和 SCL 位读取
监视器(I2CMBMON)寄存器、用于帮助确定远程从机的状态。

在 CLTO 条件下、应用软件必须选择尝试总线的方式
恢复。 大多数应用可能会尝试手动切换 I2C 引脚、以强制从器件执行 LET 操作
时钟信号的频率(一种常见的解决方案是尝试在总线上强制停止)。 CLTO 为
在突发传输结束前检测到、并且总线已由主器件成功恢复、
主硬件尝试完成挂起的突发操作。 具体取决于的状态

从器件在总线恢复后、总线上的实际行为会有所不同。 如果从器件恢复到某个状态
它可以确认主器件(基本上、它在总线挂起之前的位置)、它继续在哪里
它离开了。 但是、如果从器件恢复到复位状态(或者如果主器件强制停止导致)
从器件进入空闲状态)、它可能会忽略主器件完成突发操作的尝试
NAK 是主器件发送或请求的第一个数据字节。

由于无法始终预测从器件的行为、因此建议使用应用软件
在 CLTO 期间、始终向 I2C 主机配置(I2CMCR)寄存器中的 STOP 位写入数据
中断服务例程。 这限制了主器件尝试发送或接收的数据量
总线恢复到单个字节、在单个字节在线后、主器件发出 STOP。
另一种解决方案是让应用软件在尝试之前复位 I2C 外设
以手动恢复总线。 此解决方案允许 I2C 主硬件返回到已知的
在尝试恢复阻塞的总线并防止任何不需要的数据之前处于良好(和空闲)状态
出现在线路上。

注：主时钟低电平超时计数器计算 SCL 保持低电平的整个时间
连续。 如果 SCL 在任何时候失效、主时钟低电平超时计数器为
重新载入 I2CMCLKOCNT 寄存器中的值、并从此开始递减计数
值。

您好、Charles、

感谢您的详细且有帮助的分析-一定会证明对这里的许多人有用。

年轻的员工希望补充一点、TM4C123系列也具有这种有用的"CLTO"功能。   (有些人(Moi)有疑问)

我们(部分)对以下内容的用途有保留：  (真实副本如下：)

另一种解决方案是让应用软件在尝试之前复位 I2C 外设
以手动恢复总线。 此解决方案允许 I2C 主硬件返回到已知的
在尝试恢复阻塞的总线并防止任何不需要的数据之前处于良好(和空闲)状态
出现在线路上。

• 让应用程序的软件"复位"I2C 外设

我们的团队发现、大多数此类 I2C 外设不提供"专用复位引脚"。   因此、可以尝试"生成足够长的 SCL 脉冲序列"和/或"发出 I2C 停止命令"。   然而-这些并不总是成功！   因此、我们的小组建议通用 I2C 设计实现方案包括 I2C 主设备(MCU)为(每个) I2C 从设备提供独立/受控的"电源"。   (许多从器件可单独由 MCU 的 GPIO 供电-一个小型 FET 电源甚至额外的、可控制的"从电源"。)   这可确保 I2C 从器件可被复位。

• 当 I2C 从设备是 MCU 时会出现复杂问题

事实证明、复位 MCU "并不总是可取的"。   (获取的数据和就绪的数据可能会丢失、从 MCU 需要"时间才能完全重新初始化并从复位中恢复等")   相反-我的小组发现、在 MCU 主设备和 MCU 从设备之间提供"专用信号线"(GPIO)、使主设备能够"命令从设备 MCU "复位或以其他方式将其 I2C 外设恢复到正确的"就绪状态"。

此外、还应注意 I2C 信号布线应"短、直、并避免靠近噪声源和高速数据信令。"   仔细/深思熟虑的"多个 I2C 从器件的分布"(即作为"车轮中的扰流板"放置的从器件(与主器件等距)、而不是"菊花链式"、这会使"最远的器件面临高干扰风险。")

您好 CB1、

 感谢您与社区分享宝贵的见解和系统级经验。 我喜欢您将 GPIO 用作复位从 MCU I2C 器件的方法。 如果从 MCU 不受引脚限制、则从 MCU 可以根据 GPIO 输入专门重置其 I2C、而不是整个器件。  

查尔斯、您好！

谢谢您-希望"我们的经验和我们建议的合理性"能为"让他人受益！"   (如果可能犯错(这里的员工)... 好的-我已经把它们全部制作好了。)   [注明为"员工编辑！"]

另请注意、许多/大多数 I2C 从设备可能会"断电"-不会干扰 I2C 总线-从而节省(部分)功耗。   (可能-通过"减少有源器件的数量"使 I2C 总线"得到改进"！)   工作人员一再核实了这一调查结果，尽管"每一个案件"证明(有些不同)不同。

“不学习历史的人必须重蹈覆辙！”   

Charles 和 CB、您好！

非常感谢您的宝贵建议和快速支持、我将与客户讨论并进行进一步调试、一旦出现新情况、我将回复您。

谢谢。

Yan

您好、Yan、

 您是否对状态有任何更新？

您好、Charles、

客户至今没有更新、我将继续跟踪、并在出现新情况时更新状态、谢谢。

Yan

您好、Yan、

 好的。 请在有更新时回写。