Kaitlyn Mazzarella

If you’ve ever programmed anything in your life, you know the feeling of relief that comes with writing your code and having it work with no errors on your first try. Back in the days of Computer Science 101, this was much more feasible. Unfortunately, it rarely happens in the real world, although trial and error can sometimes be how we learn.

Take designing an Inter-Integrated Circuit (I²C) bus, for example. Many designers use I²C for its simplicity – however, the specification is still 64 pages of rules on how to communicate with the protocol. When your first printed circuit board (PCB) comes back and your I²C bus isn’t communicating properly, you’re in for a long night and a huge headache. So in this post, I’ll identify two very common I²C bus problems and introduce solutions to address them.

Headache No. 1: Static Voltage Offset Mismatch

I²C slave devices send a signal to the I²C master when they have data to transmit, and they do this by pulling the bus to a low state. A common headache with I²C bus design is when the output low voltage (V_OL) of one device is not low enough to meet the threshold of another device’s input low voltage (V_IL) requirement. The I²C standard states that a “low” is 30% of the V_CC value, and anything above 70% of V_CC is a “high.” This leaves an undefined region between the two thresholds, as shown in Figure 1.

Figure 1 I²C Voltage-level Thresholds

Ideally, your V_OL spec should be as close to 0V as possible, in order to eliminate any potential to hit the undefined range after considering other parasitics such as series resistance or high current loads. Previously, most I²C devices (such as the TCA9517) had a static voltage offset, which results in a V_OL of ~0.5V. However, TI has developed a new architecture that eliminates the requirement for a static voltage offset, resulting in a V_OL of ~0.2V for the TCA9802, one variant of this new family of TCA980x products.

Headache No. 2: Rise-time Violations

One benefit of I²C is that it can communicate with multiple devices on the same bus, as long as you limit the capacitance to 400pF. However, additional considerations come into play here as well. Headache No. 2 is often associated with rise-time issues caused by systems with complex I²C buses, either caused by having many devices on the bus or long board traces. This type of heavily loaded bus will result in large capacitance with traditional I²C buffer devices, which will in turn slow down the rising edge of your signal. The new series of I²C buffer devices uses an integrated current source to drive the bus, rather than pull-up resistor-based devices (shown in Figure 2).

https://e2e.ti.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-25/i2c-2a.png

Figure 2 Architecture of a Traditional I²C Buffer (a) vs. the TCA980x Buffer (b)

This constant current drive enables a quicker rise time and a more controlled falling edge, resulting in much stronger signal integrity, as shown in Figure 3. The light blue signal in Figure 3 shows the new current source-based architecture compared with a competitor solution shown in dark blue. This new architecture helps prevent ringing on the falling edge, which will also prevent noise reflections on the bus.

Figure 3 TCA980x Rise-time Benefit vs. the Competition

TI’s new architecture takes these common design headaches into consideration and provides simple solutions to prevent them. I²C is a standard that intends to simplify designs, which is exactly what the new TCA980x family helps do.

For more details about solving problems with this device family, read the application report, “Advantages and Design Considerations of the TCA980x Family” or see the full portfolio.

Additional Resources

• Learn more about TI’s portfolio of I²C buffered translators, I/O expanders and switches.
• Find the right device for your application with the application report, “Choosing the Correct I²C Device for New Designs.”
• Watch this video which provides additional details about the the TCA980x family benefits.