PCA9546A I2C MUX Bus Problem Why?

[berntau]

Hi,

I designed this into a new product or ours.

I notice that the chip frequently results in an I2C bus stuck event that needs recovery.

This occurs when writing the control register for a MUX selection, followed immediately bu a read to confirm the correct selection.

The bus will sometimes become stuck in that SDA remains low forever or until bus recovery procedure.

The bus become stuck at around bit 8 or Ack of read data address. See attached wave capture.

This happens at a frequency of around 1 in 1000 or in my case about every 3 minutes.

Bus operation is 100kHz.

What can cause this problem?

The bus signals are clear and beautiful. Is there a minimum time specification between a write followed by read ?

I cannot see it in the datasheet.

Regards

Bernt

[bgoedel]

Dear Tomas,

I have exactly the same issue as Bernt described. Is there any solution to it?

I have a setup consisting of an MCU (AT90USB1287) that is master to an I²C (or TWI) bus. In fact there are 4 I²C buses, the "master bus" containing all components that are needed for the normal operation and 3 I²C EEPROMs on the 3 other buses that need to be configured during Firmware startup.

When I switch from bus 0 ("master") to bus 1, this sometimes works (but not always). Yet switching from bus 1 to bus 2 doesn't work. As Bernt described, the MCU issues a STOP condition by letting the SCL go high and then waits for the SDA to go high as well. But it doesn't.

I tried to integrate waiting loops here and there, so that all bytes on the bus are timely separated, but no luck.

Pull up resistors on all buses are 10k. Shall they be lower?

I'm out of ideas, so any help would be highly appreciated!

Kind regards,
Bernhard

[TomasVaverka]

Hi Bernt,

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!

Best regards,

Tomas

[berntau]

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.

[TomasVaverka]

Hi Bernt,

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?

Best regards,

Tomas

[berntau]

Hi Tomas,

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.

Best regards

B

[TomasVaverka]

Hi Bernt,

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.

Best regards,

Tomas

[berntau]