PCA9546A I2C MUX Bus Problem Why?

cancel
Showing results for 
Search instead for 
Did you mean: 

PCA9546A I2C MUX Bus Problem Why?

198 Views
Contributor I

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

0 Kudos
6 Replies

110 Views
NXP TechSupport
NXP TechSupport

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).

Dynamic Characterstics.JPG

I hope it helps!

Best regards,

Tomas

0 Kudos

110 Views
Contributor I

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.

0 Kudos

110 Views
NXP TechSupport
NXP TechSupport

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

0 Kudos

110 Views
Contributor I

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

0 Kudos

110 Views
NXP TechSupport
NXP TechSupport

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

0 Kudos

110 Views
Contributor I

scope_41.png

0 Kudos