SSZTC18 october 2015 TCA9548A , TCA9617B
Electronic products such as smartphones, tablets, TVs, cars … even refrigerators and washing machines have added more and more features over the last few years to make life easier for users. To play games and monitor your health on a smartphone, you need haptic control and a touchscreen interface, which require additional sensors. Other systems in the automotive, industrial, communication markets have also added more sensors. Example systems include:
Many times these sensors communicate with the microprocessor/microcontroller (MCU) or with one another using the I2C interface. These sensors can be integrated circuits (ICs) with different functionality (for example, temperature sensor, pressure sensor, touchscreen interface), or they can be the same IC needed at multiple locations on the board (such as multiple temperature sensors). When system engineers draw a schematic of such a system, the I2C “tree” can get complicated, as shown in Figure 1. A complicated I2C tree can sometimes cause communication errors between the device and MCU, as degrading signal integrity can result in missed bits. Such an error can be pretty painful to debug, or worse, lead to product recalls.
Using I2C switches and repeaters significantly simplifies an I2C tree. You can use an I2C switch to split the I2C bus into multiple downstream I2C buses, as shown in Figure 2, splitting the I2C slaves into multiple I2C buses. You can select each downstream I2C path based on which slave needs to communicate with the MCU. In Figure 2, multiple IC’s of the same slave are split between different I2C downstream channels.
If only one downstream channel is turned on at a time, there should not be any issues (unless more than 15 slaves are connected on one channel). There could be scenarios, however, where multiple paths need to be on at the same time. If multiple slaves are on the upstream I2C bus at the same time, there could be signal-integrity issues, which could result in miscommunication. Assume that each slave device will contribute ~15pF of capacitance on the I2C bus, and the overall capacitance on the bus cannot exceed the I2C specification level. Figure 3 shows how using I2C repeaters resolves such issues. The I2C repeater buffers the I2C signal, allowing the connection of multiple slaves to the downstream bus.
Figure 4 shows the clock (SCL) waveform at the input (SCL_in) and the output of the switch (SCL_out1 from Figure 2). Multiple slaves (> 25) are connected to the I2C bus, with a TCA9617B repeater added to the downstream path to improve signal quality (SCL_out2, Figure 3). As you can see from the figure, the SCL_out1 waveform has signal-integrity issues and can result in missed bits at a higher capacitance load. The SCL_out2 signal with the addition of the repeater shows much-improved signal-integrity characteristics.
Each channel may not require the addition of a repeater; you can look at the waveforms on the oscilloscope to determine this. Another issue you may see, when many slaves on the I2C bus increase capacitance, is related to pull-up strength. To improve the signal integrity caused by increasing capacitance, system engineers usually decrease the size of the pull-up resistor. However, this can cause issues pulling down the signal, as the slaves may not have strong enough pull-down. There is a limit to how much current a slave device can safely sink to ground (IOL). Adding a repeater helps increase the pull-down strength.
This technique is a useful strategy to implement into complex I2C trees and avoid any signal-integrity-related issues.