1

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,

dtparam=i2c_arm=on
dtoverlay=i2c-mux,pca9548,addr=0x70

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.

Improve this question
5
  • The Pi has I2C pull-ups. You shouldn't need any others. I doubt that's the problem though. Personally I would drive the multiplexer directly rather than using the kernel (i.e. I would select the sensors by writing to the multiplexer).
    – joan
    Commented Dec 13, 2020 at 23:54
  • 1
    @joan I can reproduce the behaviour without using the overlay.
    – Duncan Drennan
    Commented Dec 14, 2020 at 0:10
  • I don't think you have given the whole story. If the only problem is i2cdetect stops working I suggest you stop using i2cdetect.
    – joan
    Commented Dec 14, 2020 at 9:10
  • 1
    @joan, I've added more info and hopefully made it clear that this is not only a i2cdetect issue, but appears to be a mux chip issue. I can reproduce the behaviour using different command line tools.
    – Duncan Drennan
    Commented Dec 14, 2020 at 9:39
  • 1
    I would try my pigs utility to see if that can reliably read the device. If it can't then that pretty much suggests a occasional wiring problem (loose?) or a duff multiplexer (unlikely). Use i2co, i2crd, and i2cwd commands.
    – joan
    Commented Dec 14, 2020 at 9:50

1 Answer 1

Reset to default
2

You should measure the bus between the Pi and the multiplexer: if the bus between the multiplexer and the sensor is silent when the issue appears, then by all means the problem should be in that the multiplexer doesn't understand the commands that the Pi is sending to it.

I didn't tread the datasheet but my gut feeling tells me there might be a timeout or an error condition which requires selecting the active bus again. If this is on a breadboard, check your wiring for intermittent connection issues.

Improve this answer
6
  • There is activity between the Pi & the Mux when things die, but it doesn't go through. I'll check the datasheet to see how it handles errors. I was wondering about what happens when things go wrong and how the i2c-mux handles that.
    – Duncan Drennan
    Commented Dec 14, 2020 at 12:19
  • @DuncanDrennan I'm sure there is "activity", but does the content present on the bus correspond to what you intend to transmit?
    – Dmitry Grigoryev
    Commented Dec 14, 2020 at 12:21
  • 1
    I see the expected data up to the point when the mux stops passing the data through. At that point there is no longer the ACK from the slave, but that is to be expected as the slave isn't getting the SCL/SDA lines anymore. I have a scope hooked up to the SCL on the mux input and the SDA on the bus output. If I then move the scope over to the SDA on the mux input, I get the expected address data on SCL when trying to read it, but no ACK (as nothing goes to the sensor). PS. this is on a printed circuit board, not a breadboard
    – Duncan Drennan
    Commented Dec 14, 2020 at 21:58
  • 1
    I did quite a bit of investigation and from what I can see the bits on the bus are correct, and the lines are switching quickly (at 100kHz and 10khz i2c clock rate). I also tried driving the nRESET line high, but I haven't looked to see if something is causing the POR of the mux to trigger unexpectedly. There is decoupling on the VCC line, but maybe it needs some bulk capacitance. As I'm writing this I'm thinking that either the POR, or noise on the nRESET line may be the problem. I do see ringing on the falling edge of the SCL. I'll try to take a look at this today, else it will be next year.
    – Duncan Drennan
    Commented Dec 17, 2020 at 8:40
  • 1
    Noise on the nRESET line! Some small hardware mods (stronger nRESET pull-up, adding a small filter cap to the nRESET and bulk decoupling) have solved this. I did all three in one go, so can't say exactly which had the biggest impact. I was able to measure noise glitches on the nRESET line down to 1.5V before the mods, and after mods noise doesn't go below 2.6V.
    – Duncan Drennan
    Commented Jan 15, 2021 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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