扫码关注
I²C主机还在跑，SCL为何被从机拉低？
主机把SCL输出设为高，只表示它释放了总线；实际电平仍可能被支持时钟延展的从机保持为低
主机发送完一个字节，程序准备进入下一拍，逻辑分析仪上的SCL却停在低电平。有人立刻判断从机死机，也有人不断缩短上拉电阻。其实在I²C规范里，从机拉低SCL可能是一种合法的等待动作。
关键在开漏结构：器件可以主动拉低，却不能主动推高。所谓输出高电平，实际动作是释放引脚，让上拉电阻把总线抬高。
只要从机仍拉低SCL，线上就保持低。主机必须读取真实SCL，而不是只相信自己的内部时钟已经走到高电平阶段。
线与结构让低电平拥有决定权
SDA和SCL通过上拉电阻保持空闲高电平，任何接入器件的开漏晶体管导通都会把线拉低。
这种结构允许多器件共享总线，也让仲裁、应答和时钟同步能够在同一对线上完成。
图1 I²C多器件共享SDA/SCL，上拉负责高电平，器件只主动拉低
排查时要区分主机寄存器的输出意图与引脚实际电平；两者不同，正是时钟延展出现的基础。
硬件I²C外设是否支持延展，不能只看协议名称。有的控制器在主模式会自动等待SCL变高，有的高速或特殊模式会限制等待方式，软件模拟I²C则完全取决于代码是否读取引脚。驱动若只按固定Delay翻转GPIO，就可能在从机拉低期间继续修改SDA。选用新主控或移植驱动时，应把这一行为列为兼容性检查项。
协议分析仪显示一个很长的SCL LOW时，应回到模拟电平确认是谁在拉低。数字解码只说明门限结果，不能区分主动驱动与RC上升。
SDA变化必须服从SCL的真实状态正常位传输要求SCL高电平期间SDA稳定，数据变化安排在SCL低电平阶段。
若主机内部认为SCL已经高，而线路仍被从机拉低，提前改变SDA会打乱从机看到的位边界。
图2 I²C数据位在SCL高电平期间保持稳定
支持clock stretching的控制器会等待SCL实际释放，再开始计算高电平时间并采样数据。
上拉过慢与时钟延展在逻辑波形上都可能表现为高电平来得晚，但电气特征不同：延展期间SCL被低阻主动拉住，释放后按RC斜率上升；电容过大时则从一开始就是缓慢爬升。示波器模拟通道比只看协议解码更有判断力。可同时测低电平电压、上升时间和从机处理时长，避免把换电阻当成所有长低电平的答案。
电平转换器也可能改变延展行为。双向MOS结构、缓冲器或隔离器若不能正确传递低电平，主从两侧看到的SCL状态可能不一致。
延展和多主机同步都利用同一物理规则多个时钟源同时接入时，最先拉低的器件开始低电平阶段，最后释放低电平的器件决定SCL何时真正升高。
图3 SCL同步波形显示低电平由仍在拉低总线的器件延长
从机延展也是把自己的处理时间映射为更长的SCL低电平，只是参与者从多个主机变成了主从。
这说明超时应从实际SCL低电平持续时间定义，而不是只数主机已经发出了多少个时钟命令。
从机常在收到一个字节并完成ACK后需要时间搬运数据、准备下一字节或等待内部状态，于是把SCL保持为低。不同器件允许延展的位置和最长时间可能不同，传感器测量、EEPROM内部写入与桥接器缓存处理也不是同一机制。主机超时应参考目标器件最坏工况，并留出温度和时钟公差，而不是随意设一个很短的毫秒数。
低功耗从机唤醒通常比正常字节处理更慢。若问题只在休眠恢复后出现，应单独核对唤醒延展时间与主机第一次访问的超时。
看到长低电平，按三类原因判断器件手册明确支持延展、随后能释放SCL，通常属于协议允许的等待；主机要确认硬件和驱动是否支持。
图4 NXP规范明确说明从机可保持SCL为低，直到准备好下一字节
SCL缓慢上升但没有被持续强拉低，更像上拉电阻、总线电容或电平门限问题。
超过从机规定处理时间仍不释放，则要检查供电、复位、固件状态与总线恢复，并设置有边界的超时，不能无限等待。
若SCL永久为低，恢复动作要有边界。先确认是哪一端在拉低，再检查从机电源、复位与SDA状态；允许时可按器件建议产生恢复时钟并重新发STOP。恢复失败就退出业务事务并上报故障，不能在主循环里无限重试。多主机场景还要防止恢复脉冲打断其他主机，任何手动拉线操作都应建立在总线所有权明确的前提下。
调试日志记录事务阶段比只写TIMEOUT更有用。标出地址、读写方向、字节序号和当时SCL/SDA电平，下一次就能定位等待发生的位置。
结论
SCL被拉低不等于故障，是否故障要看器件是否支持延展、低电平持续多久，以及最终能否合法释放。
抓波形时把SCL、SDA、事务阶段和软件超时放在同一时间轴，能快速分开合法等待、上升沿问题与真正卡死。
声明：
本文由凡亿教育整理，转载请注明来源！
投稿/招聘/广告/课程合作/资源置换 请加微信：13237418207
![电子设计：时域处理知识小结 [学以致用系列课程之数字信号处理]](https://api.fanyedu.com/uploads/image/fe/99e439f4b2c8deac5efb272581d4db.png)
