I2C multiplexing problem

[JacquesBBB]

I have multiplexed some I2C connections using a TCA9548 chip.

SCL  ->      SCL1
       ->       SCL2

SDA  ->      SDA1
        ->      SDA2

Unfortunately, the connection to SDA2 is missing in my board ( I did not noticed it was not hooked in Eagle).

There is no way I can solder a wire on the SDA2 pin of  the TSSOP TCA9548. This is beyond my soldering capabilities.
I have tried with no success.

The other thing I can do, is to by pass the  TCA9548 for the SDA2 pin, and hook it directly to  the input SDA. I have tried,
and at least for the configuration of the MS5611 which I am using, it works.

Will there be any problem with this half way multiplexing ?  Thanks for any hint.

PS : So in my design, SDA2 is always connected to SDA, whatever the connection  SDA  <->    SDA1 is .

[macboy]

This should be fine. The data and clock lines are open-drain (open-collector) and are designed to be connected to multiple devices anyway. With no activity on the clock line, the other device should ignore the toggling on the data line and remain idle.

Why did you multiplex the bus in the first place? What devices are on the two buses?

[Fungus]

With no activity on the clock line, the other device should ignore the toggling on the data line and remain idle.

Nope. A change on the data line with the clock line held high is a special signal in I2C (ie. a START or STOP condition).

It will drive all the slave devices crazy if you do that.

[JacquesBBB]

Why did you multiplex the bus in the first place? What devices are on the two buses?

I use  several instances of the same device (MSP5611). This is why I need a multiplexer.

[macboy]

http://www.nxp.com/documents/user_manual/UM10204.pdf  and http://esd.cs.ucr.edu/webres/i2c20.pdf  both say:

"A START condition immediately followed by a STOP condition (void message) is an
illegal format. Many devices however are designed to operate properly under this
condition."

also:
"I2C-bus compatible devices must reset their bus logic on receipt of a START or
repeated START condition such that they all anticipate the sending of a slave
address, even if these START conditions are not positioned according to the proper
format."

It is likely that many devices will discard a void message and go back to a valid state, but some may not. So if the OP wants  to use this configuration, he must test, test, test. 

[JacquesBBB]

It is likely that many devices will discard a void message and go back to a valid state, but some may not. So if the OP wants  to use this configuration, he must test, test, test.

Thanks to both for these  answers. I have started to test, and up to now,  it seems to work OK. That is  nothing stalled, and  the device that is  answering is the one that is selected on the SCL line, as if the one that has  a idle (HIGH) SCL is not active.

I am not sure I properly understand your answers. Is there a definite test I can do to be sure that everything is  OK.

In any case, this will not  be  the final design, but I may well need to stay for one or two months with this setting, until  I make a revision of the board.

[andre_teprom]

How about you use the A0 (pin 22) and A1 (pin23) to set separated addresses for each chip?
For instance: Soldering on a chip in the A0 to VCC (pin21), and another chip A1 to A0
This obviously just if you have not connected them to GND.

[JacquesBBB]

I have 8 MS5611 dispatched in 4 banks of 2 ( with the different I2C addresses).

I simplified the question to isolate the problem.

[Fungus]

I am not sure I properly understand your answers.

You're not supposed to change the state of SDA when SCL is high (at least: Not unless you intend to communicate on that bus).

Is there a definite test I can do to be sure that everything is  OK.

For each device, keep SCL HIGH and put ten seconds of random noise on SDA. Now put SDA back to HIGH and see if you can communicate with the device normally. Do this a dozen times.

It's not a mathematical proof that the device will always work but it should weed out the unstable ones.

[Fungus]

It is likely that many devices will discard a void message and go back to a valid state, but some may not. So if the OP wants  to use this configuration, he must test, test, test.

If it's a microcontroller slave then it could cause multiple interrupts/timeouts. Who knows what a buggy I2C driver will do?