EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
本帖最后由 alexwang 于 2021-12-13 11:11 编辑
; y* O @0 c7 A' v9 A" i1 Z$ w0 M2 a7 H0 F+ U, s
I2C七宗罪之第七罪——Clock Stretch " | T0 u. Z4 x, B ^- I) ]1 N- }! P1 x4 ]& F" X( r
EDA365原创 作者：John版主
' j3 L+ _) n0 R) U" v3 g: b
1 ~& ]0 `' m+ O7 x* [* ?由于前段时间工作上的事情比较杂乱， 导致第七罪姗姗来迟，既然是大结局，当然就应该让大家更加深刻的来理解I2C.。我们先来复习一下大家共有的对I2C的认知：
) f5 E) o2 D8 r4 y# \
1. I2C的SCL(Clock)总是由Master来驱动； 2. I2C的SDA (Data)则不同，Master和Slave分别都驱动。 6 o {0 _$ k) x' P9 p+ o3 X0 a
# A/ O/ r' Z- w 这两点想必读者都没有什么疑问，因为前面的六宗罪都已经说得比较多了，我们今天要说的是另外一种特殊情况，就是Slave也会去Drive。 / C1 d7 G9 o5 A9 s+ ^
先来看一个例子，我的一个项目发生过这样一件事情，CPU在访问板子上的另外一颗SENSOR时，一直Fail，我们非常仔细检查了时序，都是准确的。
+ P# V8 R5 v( ]6 }9 C9 }% O
注意：这里我们发现是有一个知识盲点，导致一直找不到Root Cause。
s5 W/ Z F; v
& H# l1 o6 a y" d2 ?3 m细心的工程师会在测量过程中发现， SCL上有下图这样的尖尖的毛刺，毛刺有矮的也有高的，于是我们认为SCL上这种尖毛刺会导致Slave的状态机误触发，跑飞了。
8 g. y+ a- S+ V3 m: c: F1 S
3 \" J9 ~" g& l% W& n整整一个星期我们都是这么认为的，尝试各种方法试图去消除这个毛刺。 ( f% Y7 d) {$ U1 z+ A/ P: W! h' K
因为信号从主板通过连接器到子板，我们认为这里的SCL信号很容易受到外部的干扰，比如从空间耦合过来的噪声。
0 M+ X3 {, p; p/ `
所以在信号上加电容、加匹配、降低上拉电阻等等，试图滤除毛刺。
W) w* \% T- o) M
得到的效果是，即便我们滤除的毛刺有改善，可问题依然存在，只是稍有好转。 ' m6 R0 C' B) G& j; t
0 L& x7 o+ J* W1 M5 }, J, j1 t! u 虽然说，现在拿着结果来讲故事听起来很轻松，其实那个过程真的很难受，我们接着往下看。
: m0 n. _" u, C. |5 Z
8 u! ~2 N1 K' F! l1 V8 v- V
$ x( h! c; ^% f* s俗话说三人行必有我师，有个聪明的工程师突然想到I2C有个Clock stretch的机制，来看这张图，我们看到Slave把SCL拉到低，这是什么情况呢？
1 }4 }9 w: Y; n. Y9 M
先来叙述一下Clock Stretch:
9 [7 F8 b* X' o5 ~6 ^9 M9 U
1. 当Master是高速I2C设备，Slave是Low Speed设备时，Master输出的SCL的频率超出了Slave的承受范围，此时Slave跟不上Master的速度怎么办？ Slave就要想办法告诉Master。
1 G3 I: f& q1 J% ~5 |% O
( u5 |- Z6 _) Z7 J( i" j% t* a7 G1 g! `9 l& z
% v9 r: c, T9 M5 q" t$ ~& G- h+ O6 T
大家知道为什么这里会看到右边矮矮的Glitch吗？ 8 r9 f+ J# q# t
/ z- T0 [& u7 c' G. H- s1 X 因为Master此时是想驱动SCL高电平，而Slave却拖住SCL不让变为高电平，这个其实是一种想象，实际测试是看不到的，这里是为了方便大家理解。 - \% M; `1 ^/ K( V2 s# H/ r# K6 E: a
2. 我们再来看一张图，加深一下理解，Slave会强行把SCL拉低，拖住Master，这和之前我们对I2C的认知是完全相反的，此时Slave 是输出SCL信号，而Master则是检测SCL状态的输入信号。 ; D7 V2 S. l5 @. d
/ t( F# I9 H0 u/ O1 Y* A! u" `
正常情况下Master/Slave都是通过在SDA上的ACK信号来确认一笔操作的成功，如图：
; c. l ~/ g* n( ~* h. ?( p5 U 但是如果Slave来不及怎么办？ " u2 F( U. B4 R* Z/ k
（看下图）Slave直接把SCL信号拖住告知Master：兄弟我还没有准备好，你先等等我啊。
: r4 x. b% h9 j, p; Q, C# w
此时Master要做的事情就是乖乖等着，并且一直检测SCL的状态（输入信号），当Slave松开SCL信号，由于上拉电阻的存在，SCL自然变高，Master检测到SCL变高后，才开始检测ACK信号，然后继续下一步操作。 说了那么多I2C stretch，想必大家应该理解了。
) n+ n* M; `( I q9 u$ l
回到最上面我们遇到的CPU和SENSOR之间的I2C问题，我们测量得到毛刺确实是罪魁祸首。 9 }- R6 m! {9 v* U
9 }. i0 [/ O4 D$ \0 }+ [( } 因为此时CPU和SENSOR进入了Clock Stretch， Sensor拉低了SCL，而CPU Master不断地检测SCL的状态，期待高电平的到来，此时毛刺就误导了CPU，CPU看到尖的毛刺就认为Slave已经松开了SCL，就立刻开始下一步的动作，此时Slave很冤枉了，自己明明拉低了SCL让Master等着，可是这位兄弟怎么这么不听话呢？
$ N. h# V# w: z4 G/ D9 k, I
/ n. D3 z) y3 |9 w# r. e. Z& N' Q解决的方法很简单，CPU的I2C控制器在进入Clock Stretch时，检测SCL并且判断高电平时有一个De-Glitch的功能，我们之前没有打开，打开后就可以滤除Glitch这样的窄脉冲了。 - o9 A4 A8 D7 X$ r W' \7 V* m. ^
# ~$ W8 r3 L- j* ` @ I- R% ? 简单一点讲，就是当检测到一个SCL的高，用一个计数器继续连续计数，只有发现连续的40个高电平才认为是SCL真的拉高了，否则就认为是毛刺，不予理睬。 / J+ Y- u, \ r j
聪明的人很多，我们再来说说最近碰到的另外一件关于Clock Stretching的事情。
! X; G/ [' C+ v/ k9 L/ T8 t+ X" K- K紫色的线有一段半高， 其实原因也简单，就是因为此时Slave拉低SCL，但是Master不支持Clock Stretch，此时就发生了冲突。 r% f6 N5 [. ^
6 [3 N( q. U2 }9 K! P+ ? Master不支持Clock Stretch，我们就需要通过软件的方式去模拟，此时有两件事需要实现： A9 a; O+ Z* P$ |
1. Master要把SCL切换为输入，然后不停检测SCL的状态； 2. Master在检测SCL状态一定要做De-bounce或者De-Glitch的滤波。
1 Q% x3 P9 N; i. V9 ~ @
看完了上面的叙述，想必大家都可以理解原因。可是这样会让软件工程师们很麻烦，那么应该怎样绕开Clock Stretch呢？ 聪明的工程师总有自己的办法。
: E0 s$ P9 C: r; [/ j9 F我们和Slave芯片的Vendor确认，每次Slave在做ACK后，芯片需要最多5ms的Clock Stretch延时。 7 a' U! s& t) B7 Q& F- s+ C% P
- g1 l# r5 K8 z+ \7 I6 u5 V& | 我们拿到这个数字后，软件工程师只要注意在Master每次得到ACK后，先等待5ms后再对Slave做下一笔操作。 4 S \+ U& r" X# R6 a; S3 p0 j& @; Q% B) N* ]4 O0 @
在这个5ms期间Master完全不用关心 SCL信号上是高电平和低电平，因为5ms以后Slave肯定松开了SCL，也就是说SCL肯定是高电平了。 , L! b* g9 {1 D$ V$ }
这种方法就避免Master的SCL信号切换为输入，还要不停地检测SCL的状态，最重要的是不需要做软件的De-bounce或者De-Glitch算法。 4 E4 v3 s. i3 G# @+ _6 _1 y& h
0 x, }. p) h* |2 O6 X( o7 {, ?2 n' t w9 q6 q% g
自此I2C的七宗罪就结束了，希望这七宗罪可以cover所有硬件设计过程中的I2C问题，到目前我还没有发现有其它超出这七个范围的问题。 排版编辑丨陆妹 / O- I" `3 v( u* I4 i# {
注：本文为EDA365电子论坛原创文章，未经允许，不得转载。 . W8 k' g+ M0 V2 l8 _) d
| 
/1 
发表于 2019-6-14 15:44
收藏
淘帖
支持！
反对！
楼主
8 e; f4 U5 K: G+ x& R8 t