0
\$\begingroup\$

In an application I have multiple I2C slave devices: display, RTC, and EEPROM. The most crititcal is the RTC, which needs to work 100%.

I read that I2C freezes from time to time. At the moment all 3 devices are on one I2C bus. Would it be better to use the RTC on a seperate I2C line? My MCU is a SAMD21 which has up to 6 I2C lines.

\$\endgroup\$
6
  • 5
    \$\begingroup\$ Please link to the document that says I2C freezes. \$\endgroup\$ – Andy aka Jan 14 at 14:44
  • \$\begingroup\$ Which exact display, which exact RTC, which exact EEPROM, which exact SAMD21? Are they all using the same supply voltage node? Have you read all documentation and errata if the chips have no quirks to prevent them from putting them into same bus? \$\endgroup\$ – Justme Jan 14 at 15:02
  • \$\begingroup\$ @user - -random side note - you need them all of them to work 100%, with margin to spare. More details plz: are you on a single PCB? bunch of wires flying around? how long? cable construction, if any? bus speed? supply voltage? \$\endgroup\$ – Pete W Jan 14 at 15:26
  • \$\begingroup\$ RTC is AB1805, EEPROM 24CW1280T-I/SN, ATSAMD21G18A-AU, but it's not only a matter of those components as in another project I may have different ones but the question and problem on haning I2C is the same. You can use google to find a lot of expereinces of a freezed I2C bus and the statement of I2C not beeing a reliable bus. In this case it's a single PCB 6cmx6cm, dcdc vonverter, approx 8V battery supply \$\endgroup\$ – user3435167 Jan 15 at 11:59
  • \$\begingroup\$ From the SAM D21/DA1 Family datasheet: Peripherals: 32-bit Real Time Counter (RTC) with clock/calendar function. Why do you need an external one? \$\endgroup\$ – Rodo Jan 15 at 21:58
3
\$\begingroup\$

I2C will never freeze if used properly. But that's like saying that there would be no crimes if everyone just followed the law. There certainly exist masters and slaves that break the rules of I2C under certain circumstances.

You can minimize the risks of a badly-behaved device messing everything up in several ways:

  1. As you suggest, put a crucial slave on its own bus if you believe that the other slaves might be untrustworthy.
  2. Don't power up, or cut power, to any slave while traffic could be running. They should be able to power up and down without pulling the bus down, but some of them can't.
  3. Have your system send a reset to all devices if the bus is pulled down for too long (the constraints of your system will determine how long is "too long.")
  4. Be careful about capacitance and resistance, so that you have decently fast rise times. Otherwise, your master could think that it needs to stretch the clock. (This shouldn't freeze the system, but it's nothing you want).
  5. Avoid clock stretching by slaves as much as possible.

And, of course, use trustworthy devices as much as possible.

\$\endgroup\$
2
  • \$\begingroup\$ That's a good answer I can work with! I will now put the rtc to a sperate bus as indeed I'm cutting the power of the OLED. >And, of course, use trustworthy devices as much as possible. How do you know which is a trustworthy device or not? \$\endgroup\$ – user3435167 Jan 15 at 19:01
  • \$\begingroup\$ @user3435167 I wish I had a precise answer for that. I tend to put more trust in devices that have been on the market for longer, and have been used in mass production. Or devices that have the same I2C IP as another device that fits those criteria. I tend to be less trustful of devices with a lot of "sexy" I2C features, since simple things are more likely to be done correctly. \$\endgroup\$ – Annie Jan 15 at 22:59
2
\$\begingroup\$

I2C's reputation for not being reliable has a handful of common causes that come up again and again. For the most part, prevented by ordinary design practices. The general advice of reducing bus speed does not necessarily prevent it, rather it makes it easier to apply fixes if needed.

Causes on the hardware side

  • false falling edges on SCK from crosstalk between SDA and SCL (i.e. when SDA is transitioning, SCL supposed to remain high but sees a glitch). This is an issue when cables length gets into multiple meters. Can mitigate by reducing dV/dt via controlled rate driver, or series resistance (forming RC vs bulk capacitance); constant-current pull-up; higher VDD; and even cable construction (SDA/SCL wire position not adjacent, PVC vs PPE inner insulation - lower dielectric constant insulation better). But really, i2c shouldn't be going into cables of any significant length.
  • false/double falling edges on SCK from t-line effects. Fix: reduce dV/dt of the falling edges, and terminate the active end, with some series resistance (33-100 ohm range). If long line, perhaps use twisted pairs (each signal vs GND, not SDA/SCL together!). Note that due to open drain drivers, series termination only effective when line is pulled low.
  • false falling edges on SCK from ground bounce. In this case, excessive pull-up current can actually be the root cause (open drain activates, dI/dt raises GND locally vs signal line) and attempting to fix the problem with stronger pull up would make it worse. Likewise, making lines longer also increase dI/dt due to larger cap. Either way, this issue is likely a matter of bypass/grounding. Constant-current pull-up can be involved in the fix, if the situation is simultaneously constrained by rise time vs total capacitance, because it CC-pullup can reduce the amount of current needed to achieve the rise time. Root cause could also be just (particularly bad) general supply noise.
  • Excessive rise time due to capacitance. In this case, stronger pull-up is the right thing to do. Again, think twice if using i2c with long cables.

The above can happen in combination. In case of adding series resistance, be aware that it will raise the "low" signal level by I_pullup*R_series, so don't overdo it.

On the firmware side

  • Some devices need min and/or max delays, between bytes, between multi-byte words, between sessions, or when starting(?). One bad experience I had with OEM sensors in a niche market, the device vendor didn't fully document these timing requirements and I had to deduce them -- massively frustrating. The "wrong" delay caused the confused device to pull the bus low and then remain in that state.
\$\endgroup\$

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.