I am seeing an unexpected side effect, and could use some pointers. I am working on a project which uses five TCS34725 color sensors. These sensors are being interfaced via I2C on a TI F28069M DSP Launchpad. The first problem I faced was that the color sensors all have the same address (and they cannot be rewritten). I was given a DG407 dual 8 channel analog mux to attempt a solution. At first I thought this solution was rather straightforward -- I'd use the mux for SDA and SCL. What I am seeing however is that the first mux address I set, works perfectly fine, I can read the color sensor ID and read/write config registers etc. The next mux address I set, causes the I2C bus to register as busy on the TI DSP.

My theory is that the mux transitions temporarily to high impedance between address changes, and that high impedance state is somehow being seen as a start condition by the DSP, therefore forever busying the bus until a reset.

According to the DSP's technical reference manual, I can set I2CMDR.IRS bit to 1, which effectively disables the peripheral, resets its status bits, and retains its configuration. I tried setting this bit, delaying 10uS, switching the mux, waiting 10uS, then clearing the bit, but I still see the issue.

Any ideas as to how I can chase down this problem?

Circuit diagram below.


simulate this circuit – Schematic created using CircuitLab

  • \$\begingroup\$ Do you have a scope or logic analyser? \$\endgroup\$
    – uint128_t
    Mar 13 '16 at 23:04
  • \$\begingroup\$ A schematic snippet wouldn't hurt either. \$\endgroup\$ Mar 13 '16 at 23:29
  • \$\begingroup\$ @uint128_t, I do have a scope. When I scoped the SDA and SCL lines on the DSP side, I didn't see anything alarming. The bus level appeared to stay high throughout the transition. \$\endgroup\$ Mar 14 '16 at 2:26
  • \$\begingroup\$ @NickAlexeev, schematic added for clarity. \$\endgroup\$ Mar 14 '16 at 2:27
  • \$\begingroup\$ Do you have pull-up resistors on all sides of the mux? \$\endgroup\$ Mar 14 '16 at 3:17

Try putting pull-up resistors on the I2C bus on both the input and output sides of the mux. If you already have smallish resistors (1 to 2k) on the output side, then adding larger ones (10k) to the input side would be reasonable, as they would only serve to hold the high level while the mux is switched and not drive the bus from low to high.


The issue is most likely lack of resistors. Basically when you switch the multiplexer from one channel to the next, the output of the one you have just disconnected is now floating. In all likelihood it will probably float down to ground which could cause some odd start/stop conditions on the slave devices depending on which mux decays to zero first.

As a result of the switchover, the slave is probably now in some weird state and when you reconnect the mux it will still be confused and likely stop responding. I have a sneaking suspicion that if you try and access it a second time after it has failed without changing the mux, the second access may succeed as the slave logic will have been reset by the stop condition from the first failed access.

The solution is to add pull-up resistors on all branches of the mux to ensure than when disconnected, the channels float high, thus preventing spurious start/stop conditions.

You say your DSP side has internal resistors, which is fine, that holds the master branch of the bus high. But you will still need resistors on the other branches. These need only be low strength pull-ups as they are not trying to drive the SDA/SCL edges, they are only there to hold the level when disconnected.

The 180R you tried is far, far too strong for I²C, and even 2.7k will be too strong if the master side already has reasonably strong pull-ups. As @alex.forencich suggests, 10k is probably a much more reasonable value. This should have sufficiently low drive strength to not cause your slaves any trouble. You could probably even go higher with the resistance if your slaves are struggling - maybe try 22k or 47k.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.