0
\$\begingroup\$

In my design i2c have master and one slave communicate with each other. the distance between is approx 1 meter. we put the pull-up register value 10k slave side. they working fine but some random time sda is high on 3v3 but scl goes down and the mcu goes in stuck.so after hard reset mcu turn on. and after they working fine. so please help me into this.

\$\endgroup\$
2
  • \$\begingroup\$ This is a design feature of I2C. Any glitch will upset it. The solution? Don’t use I2C! How to mitigate? Implement timeouts and reset the bus if you do get a lockup. I’d suggest you get a logic analyser to see what is happening - if your slave is misbehaving, then you’ll need to see why that is. If it is glitches, the pay attention to your wiring. \$\endgroup\$
    – Kartman
    Oct 13, 2021 at 10:22
  • \$\begingroup\$ If the problem is not in the protocol then a logic analyzer won't help much, an oscilloscope can better identify what might cause the problem - like too weak pull-ups cause slow rise time, outputs being accidentally push-pulls while one device wants to stretch the clock by pulling it low, or simply capacitive coupling between SDA and SCL. \$\endgroup\$
    – Justme
    Oct 13, 2021 at 10:32

2 Answers 2

2
\$\begingroup\$

First of all, 1m is about the limit of operation of I2C; it isn't really designed to work at these distances.

Also a 10k pull-up seems a little high, especially given the length of the line (if it's near the master or the device it doesn't really matter).

Consider that you are creating an RC circuit with the pullup and the line capacitance. If you use a smaller resistor the time constant will be lower and also the pull up become stronger (it helps with disturbances). Even 2.2k should work fine.

Go to the NXP site and download UM10204 (the I2C specs). Section 7 has all the signal details.

The real issue is that your SCL line shouldn't go down without control. A scope picture could be helpful for that. If if goes down sharply there's something really wrong since your master would be driving it (almost no slave uses clock stretching so SCL is completely master driven).

Some I2C controller are just silly and almost bugged. For example the MSP430 one is extremely timing sensitive and it's easy to get it stuck. Check all your status registers to see if something is wrong.

What data rate are you using? 100kHz or 400kHz? slowing down could help. Most peripheral can go down to about 20kHz (the I2C standard doesn't specify a minimum but some related standards like SMbus do).

The kind of cabling also matter. At one meter I doubt it's all PCB. Often I2C is routed thru flat cable. That would be about 40pF/1.45µH of load. This in not a problem for I2C (it handles about 400pF of load) but it could raise susceptibility to disturbances.

When:

  • You have ruled out a software/controller issue
  • Put on the stronger pull up you can afford
  • Tried with maybe some shielded cable and/or rerouting the cable itself

And you still see noise on the data or clock lines then maybe straight I2C is not for you application. NXP (who else?) makes some special buffers for these situations. They either boost the signal or even turn the line in some non-standard differential form: you need one of these at each side of the line and the segment is not an I2C line anymore.

\$\endgroup\$
2
  • \$\begingroup\$ Sure, I2C is not meant for long lengths, but 1m is certainly not anywhere near the limit for an I2C bus, that's just plain wrong. You most likely have much longer VGA, DVI and HDMI cables than 1m and I2C works over them just fine. So in practice, a few meters is possible without any special tricks but with careful design, and beyond a few meters starts to require special tricks. \$\endgroup\$
    – Justme
    Oct 13, 2021 at 12:21
  • \$\begingroup\$ the 'theorical' limit would be at about 10m but you'll run in problem before since I2C doesn't have error detection codes… however from the description it seems more probable a software/master issue, SCL clock doesn't go down on it's own from a disturbacne \$\endgroup\$ Oct 14, 2021 at 6:50
2
\$\begingroup\$

Terminology

NXP Semiconductors recently released v7 of the I2C-bus specification which has:

Updated the terms "master/slave" to "controller/target" throughout to align with MIPI I3C specification and NXP's Inclusive Language Project

UM10204, I2C-bus specification and user manual, v7, 2021-10-01, Table 1, Revision history

More widely, the abhorrent dyad "master/slave" is being deprecated from the field of electronics.

Timeouts

If you do a word search on the above specification for "timeout" you won't find it.

This is because there is no provision for faults that freeze the bus, so you have to implement fault recovery yourself by a separate method such as a watchdog timer or ordinary timer.

Alternatively, the SMBus specification (which is based on I2C) does have timeouts. See the SMBus Quick Start Guide by NXP.

What MCU are you using?

Here is an example of how to implement a watchdog timer for I2C with Arduino that I put on Wokwi where you can freeze the bus by pressing the orange button. When you release the button, the bus restarts.

\$\endgroup\$
2
  • \$\begingroup\$ This is a good thing to point out, but it's not an answer. Please consider making a direct edit to the post, citing this update, or if you think a community-wide effort is warranted, please ask a meta question. \$\endgroup\$
    – nanofarad
    Oct 13, 2021 at 14:16
  • \$\begingroup\$ @nanofarad, thanks, I've updated it. I also mentioned NXP's change of terminology on meta \$\endgroup\$
    – tim
    Oct 13, 2021 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.