Quick fixes to common I2C headaches

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 (I2C) bus, for example. Many designers use I2C 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 I2C 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 I2C bus problems and introduce solutions to address them.

Headache No. 1: static voltage offset mismatch

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

Figure 1: I2C voltage-level thresholds

Ideally, your VOL 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 I2C devices (such as the TCA9517) had a static voltage offset, which results in a VOL of ~0.5V. However, TI has developed a new architecture that eliminates the requirement for a static voltage offset, resulting in a VOL of ~0.2V for the TCA9802, one variant of this new family of TCA980x products.

Headache No. 2: rise-time violations

One benefit of I2C 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 I2C 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 I2C buffer devices, which will in turn slow down the rising edge of your signal. The new series of I2C buffer devices uses an integrated current source to drive the bus, rather than pull-up resistor-based devices (shown in Figure 2).

Figure 2: Architecture of a traditional I2C 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. I2C 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