Yes, it can be caused by a short interval between a write and read command. There is a minimum required bus free time which is 4.7us in Standard Mode (100kHz).
I hope it helps!
Hello, as per the attached scope capture, that condition is not violated. There is almost 100us time from STOP to START when this happens.
I have also ruled out any downstream devices as the cause.
I do apologize for my delayed response, I have been out of the office the last couple of days.
I am not sure what the root cause of this issue could be. Usually, the I2C bus hangs due to noise on the bus, odd I2C switching sequence or improper I2C start, stop… When looking at the scope shot, there are switching noises on the positive rail as well as ground. Would it possible for you to clean these up to see if it would fix the problem?
I am not sure which noise you are referring to as the signals look very clean for real world signals.
If you mean the spikes AFTER the fact, that is because the CPU switches off the I2C bus and returns to GPIO mode so that it can measure and recover the bus. That is not avoidable but as said, it is only AFTER this chip has locked up .
Also please note:
1) The problem occurs always at the same bit in the same message.
2) None of the downstream or other devices have any issues, only this particular MUX chip.
Few other questions:
1. Does the problem occur also when you try to select other channels (downstream pair)?
2. “This happens at a frequency of around 1 in 1000 or in my case about every 3 minutes.”
I do not fully understand this sentence. Does it mean the issue does not happen always when you try to read the control register?
3. How is the I2C read function implemented in your code? Since 0x70+R seems to be successfully acknowledged by PCA9546A, I would expect next 8 clock pulses on the SCL line regardless of the state of the SDA line.