EDIT [solved]: This turned out to be noise coupling to the nRESET line and causing the MUX to reset. The RPi edges are sharp, and in this case the mux is on the other side of a ribbon cable, so the SCL/SDA lines were coupling into the nRESET line. Using a stronger nRESET pull-up (changed from 10k to 4k7) and adding a small 470pF filter cap to the nRESET line has resolved this. I also added additional bulk decoupling to the MUX chip. It now works reliably with many, many I2C communication cycles
Original question below:
I have the TCA9548A connecting 3x TCS34725 sensors to the I2C bus. The i2c-mux overlay is enabled and I see all the expected buses (/dev/i2c-3 to /dev/i2c-10), with the three devices on i2c-3, 4 and 5.
If I do an i2cdetect -y 3, then it shows the correct address (0x29). The same happens when I scan buses 4 and 5.
If I scan the same bus multiple time, then after a few tries (between 1 and 4) the bus stops detecting the sensor. If I then scan a different bus, it detects the sensor, and then go back to the first bus and it detects the sensor again. i.e. successive
i2cdetect -y 3 result in the sensor no longer being detected. Then run
i2cdetect -y 4 and the second sensor is detected, then run
i2cdetect -y 3 and the first sensor is detected again.
This happens on all the buses and in all cases scanning a different bus will then cause the next scan of the bus to succeed.
In /boot/config.txt I have the following,
The muxer has 3k3-pull up resistors on the I2C bus. The sensors (which are close to the muxer) have 4k7 pull-up resistors.
I measured the bus with a scope and the RPi bus to the muxer always shows clock/data activity. If I measure the sensor bus, then I see bus activity whenever it detects the sensor correctly. In the cases where the bus appears to lock up and does not detect the sensor, there is no clock or data activity.
It seems as if something is going wrong with the multiplexer and it is not passing the clock/data through to the correct (or any) of the buses
I have tried reducing the I2C bus clock speed, but the behaviour is exactly the same.
I did try limiting the range of addresses scanned by doing
i2cdetect -y 3 0x29 0x2A which does allow more scans, but eventually this also fails. With
i2cget -y 3 0x29 0xD it works for a while too, but then starts throwing
Error: Read failed. This is also resolved by reading a different bus and reading again on the intended bus.
I tried disabling the i2c-mux overlay and setting the mux directly. I see the same behaviour where a scan shows the sensor, and then after subsequent scans the sensor can no longer be read.
Without the i2c-mux overlay enabled, I can do the following:
i2cset -y 1 0x70 0x00 0x01 // select bus 0 i2cget -y 1 0x29 0x00 // read from sensor
Again, I can do a random number of i2cget's on the 0x29 address before it starts throwing
Error: Read failed.
I'm a bit stumped on what to try next, although as I've investigated further this does not appear to be a RPi issue, but rather something related to the mux chip. I can't see why it randomly stops the output bus.