I2C Devices Interfering with Each Other When Powered via Transistors

Projects Networking, Protocols, and Devices
1

Hi everyone,
I’m encountering a puzzling issue with my Arduino Uno R3 setup and could use some insight.

My project includes:

  • Arduino Uno R3
  • MPU6050 gyroscope/accelerometer
  • 1602 I2C LCD Display
  • HiLetgo PCF8574 I/O Expander (I2C)
  • Each component is powered via individual transistors that act as electronic switches. These allow me to selectively power components based on system events in the final design.

All the I2C devices are wired to the same SDA and SCL lines on the Arduino, and I’ve triple-checked the wiring—everything looks correct.

The problem: When I use the transistors to selectively power components, some I2C devices behave erratically or cause the I2C bus to hang. Below are my test scenarios with their expected vs. actual behavior:

  1. MPU6050 = HIGH, HiLetgo I/O = LOW, and LCD = LOW:
  • What Happens: I2C scanner is stuck in scanning until both LCD and HiLetgo I/O are disconnected
  • What Should Happen: Only the MPU6050 should show up
  1. MPU6050 = LOW, HiLetgo I/O= HIGH, and LCD = LOW:
  • What Happens: MPU6050 and the HiLetgo I/O both show up
  • What Should Happen: ONLY the HiLetgo I/O should show up
  1. MPU6050 = LOW, HiLetgo I/O= LOW, and LCD = HIGH:
  • What Happens: I2C scanner stuck in scanning only until HiLetgo I/O and MPU6050 are unplugged, then only the LCD shows up
  • What Should Happen: ONLY the LCD should show up
  1. MPU6050 = HIGH, HiLetgo I/O= HIGH, and LCD = LOW:
  • What Happens: MPU6050 and HiLetgo I/O both show up
  • What Should Happen: ONLY the MPU6050 and HiLetgo I/O should show up
  1. MPU6050 = LOW, HiLetgo I/O= HIGH, and LCD = HIGH:
  • What Happens: All components show up
  • What Should Happen: ONLY the HiLetgo I/O and LCD should show up
  1. MPU6050 = HIGH, HiLetgo I/O= LOW, and LCD = HIGH:
  • What Happens: I2C scanner stuck in scanning until HiLetgo I/O is disconnected, then both the MPU6050 and the LCD both show up
  • What Should Happen: ONLY the MPU6050 and the LCD should show up
  1. MPU6050 = HIGH, HiLetgo I/O= HIGH, and LCD = HIGH:
  • What Happens: All three components show up
  • What Should Happen: All three components show up

It seems like even when a component is powered off, it can still affect the I2C bus, possibly due to leakage or interference through the SDA/SCL lines.

Has anyone experienced anything similar? Any ideas on how to isolate the devices more effectively or prevent interference from powered-off components?

Thanks in advance!

2

So you are applying SDA and SCL signals to unpowered components? That is an excellent way to create sneak paths and destroy the unpowered components by powering them through the data lines.

Also, they'll likely corrupt the I2C bus. Which sounds like what you are seeing.

3

Is there not a way to use the I2C expander to disconnect the SDA/SCL lines?

4

Basically I have all SDA and SCL lines connected to the arduino's ports, but the power (VCC) for each of the components have a transistor that blocks the power supply to the part. Are you saying that the SDA and SCL ports also have power being sent to the components at the same time, even if the power to the component is turned off?

5

Yes. Voltage is voltage, regardless of what pin it comes in on. Sneak paths are a Really Bad Idea. As you are finding out.

6

So would you say something like a TCA9548A I2C Multiplexer Breakout Board would be better for what I want to do? Maybe using both that and the transistors in sequence?

7

The multiplexer is still going to have voltage on the SDA and SCL pins. Therefore sneak paths will still exist.

I think I'm going to let someone else take over; I don't seem to be getting through. Good luck with your project.

8

Thank you for trying, I will try and also do some more research

9

The real name for "Sneak paths" is "parasitic powering"

The only legitimate use of this, is when you want to power a remote 1 wire bus device. Otherwise any other sort is a really bad idea, and will damage things.

Start your research here:-
How to prevent parasitic powering

Also it is a good idea to dispense with the word salad and post a schematic.

You might want to look at this How to get the best out of this forum before you proceed any further.
We only know what you tell us, and so far this is not sufficient.

10

Most modern sensors and display modules have sleep modes that allow them to remain powered, drawing negligible current, and in that state do not interfere with communications.

That avoids the problem that you created by powering them down individually.

Study the individual data sheets to learn the details.

11

You need to turn off the I2C on the unpowered devices. This can be done using back to back level shifters. See page 12 of this application note.

It looks complicated but you can use 2 common level shifter modules to build it.
Example is here.

EDIT: We used 4 channel converters because they were common and cheap. You only need 2 channels (one each for clock and data). There are 2 channel converters but they are less common. For example.

12

I2C should be open collector (or open drain), so I would think de-selecting the channel on the multiplexer would block any cross-feeding of power, provided each I2C device has its pull-up resistors connected to it own power source. One of the uses of the TCA9548A is to be able to interface I2C devices with different logic levels, so that one bus can have pull-ups to 3.3V, another 5V, and another as low as 1.8V.

The parasitic power does not come from the SDA or SCL pin, but through the pull-up resistors of any I2C device that has power.