I²C bus blocked

Hey guys!

I recently dicovered a problem with home-made I2C sensors, and I thought I'm going to ask if somebody experienced the same problem.

I run multiple devices on one bus line (one master, several slaves). All neat and cool, but when I disconnect the power supply of one slave (GND, SDA & SCL still connected) the whole bus is blocked.

Ok, normally this isn't a big thing, when I disconnect one device I use a 4-pin jack and all lines are cut. But out of pure curiosity: Is there a software-way to keep the bus alive?

Kind regards, deloarts!

SDA and SCL are supposed to be held high afaik; have you got pullups doing that?

Perhaps when you kill one slave's power the bus is forced low.

deloarts: Hey guys!

I recently dicovered a problem with home-made I2C sensors, and I thought I'm going to ask if somebody experienced the same problem.

I run multiple devices on one bus line (one master, several slaves). All neat and cool, but when I disconnect the power supply of one slave (GND, SDA & SCL still connected) the whole bus is blocked.

Ok, normally this isn't a big thing, when I disconnect one device I use a 4-pin jack and all lines are cut. But out of pure curiosity: Is there a software-way to keep the bus alive?

Kind regards, deloarts!

No software way, but you can use I2C switch controllers to create isolated branches of your I2C network.

I use PCA9545A's which are four channel devices. They also allow 5V to 3.3V translation, and allow me to disable any branch. I use them in a device were my I2C sensors are physically destroyed during normal use. This allows my controller, which uses I2C LCD, I2C keypad, I2C EEPROM, I2C I/O expanders to continue functioning after a sensor is destroyed. When the sensor is destroyed, it can short SDA and/or SCL to Ground, or short them to a current limited 3.3v.

Chuck.

chucktodd: my I2C sensors are physically destroyed during normal use.

That has to be a story worth hearing.

manor_royal: That has to be a story worth hearing.

Accelerometers used to measure impact force transmission to substrates. Sometimes catastrophic failure occurs.

before: |500x411 after: |500x371 |500x344

Chuck.

Sounds like something from the Mythbuster series on TV recently (a marathon). The answer to any issue seem to involve something exploding :-)

First: Thanks for your answers!

@manor_royal Yes i do use pull-up resistors, that's one of the reasons why I can't really figure out what's wrong with my setup.

@chucktodd Thanks for your adiveise with the PCA9545A muliplexer. I'm going to get one, coz now I can abandon my MOSFETs to level-shift between my devices.

deloarts: First: Thanks for your answers!

@manor_royal Yes i do use pull-up resistors, that's one of the reasons why I can't really figure out what's wrong with my setup.

when you leave unpowered device connected to a 'live' I2C network they drain power from SCL, SDA they have overvoltage diodes connecting their SCL,SDA input to their VCC pin, so if their VCC voltage is less than SCL or SDA they shunt this 'overvoltage' into their VCC rail. the effect is that SCL and SDA are pulled LOW, jamming the bus. Depending on the specific devices, they many be able to partially power up and actively Jam the bus also.

Unless a device EXPLICITLY states that it can be powered off with live inputs, NEVER allow signals to be applied to a powered off device. Most spec sheets reference the input range to VCC + 0.7v Max. If Vcc is ZERO the maximum input is limited to 0.7V (This shows the effective protection diode to VCC).

Chuck.

Thanks Chuck for that really good answer!

I think I'll try to fix that problem with optocouplers. So the controller connects itself to the bus when it has booted. The thing is: Is the I2C bus capable of this, or can such an action create a false signal?

regards!

deloarts:
Thanks Chuck for that really good answer!

I think I’ll try to fix that problem with optocouplers. So the controller connects itself to the bus when it has booted. The thing is: Is the I2C bus capable of this, or can such an action create a false signal?

regards!

I do live insertion on to a I2C bus, but I use the PCA9545 on the primary, ‘always on’ segment.
I programmatically isolate the segment before I actually insert the device. If I don’t, sometimes the insertion ‘jams’ the bus which triggers my bus recovery code.

You will have to do some research on the I2C bus, If your insertion causes a ‘start’ condition, you will have to insert a ‘stop’ to release the bus. I use the PCA9545’s !RESET input to partition my bus segments if my modified WIRE.h library returns a bus error or timeout. I reset the PCA9545 with an Arduino output, then reinitialize the I2C bus(Wire.begin():wink: then test each segment individually by scanning each segment looking for expected devices. When I ‘find’ then failed segment it sets an error state and reports the fault.

Phillips, now NXP created the I2C specification. Take a look at this document.

Chuck.

That's a really good way to restore the bus! I haven't thought about using the lib's error handlers to check the bus' state.

Thank's for giving me that cool idea, now I have something to do again!

regards!