Hello Max,

Can you please share a schematic of your system? Mainly the connection between your primary device and the PCA9548.

This will help to evaluate your issue much faster. 

Thanks,

Nir 

Hi Nir,

Sorry for the late reply.

Here are the schematics:

PANDORA BAT-INTERFACE_BQ24735_R01.pdf

PANDORA_MCU_BOARD_R01A_230413_1.pdf

Hello Max,

Thank you for the schematics. What is the signal the primary device is sending on the connection? 

I am not sure if using the RESET pin will help the issue, first I want to understand what signal is being sent to the PCA9548. 

Thanks,

Nir 

The signal is I2c - if I understand your question correctly.

Yes, at what voltage level? 

3.3V

Hello Max,

Is this an isolated event, or it happened on multiple devices? 

Also have you tried to power cycle the device?

Thanks,

Nir 

This has happened on multiple devices. Power cycling the device fixes the problem, but that is not our ideal fix if the reset line would also fix this.

Hello Max,

Were there any changes in the system design during that one month period? 

Also, are you using pull-up resistors on each channel? I see resistors in the schematic, but they don't seem to be acting as pull-ups. 

Finally, what is the maximum of channels that are ON at a given time? 

Having all 8 channels ON at the same time might cause issues. 

Thanks,

Nir 

There were no changes in the system design during that month.

If you look at the "BQ" chips SDA and SCL lines, you'll see the pull-ups.

We only have one channel on at a time. We are switching from one to the next.

Any other thoughts?

Thanks,

Max

Hello Max,

Can you please provide scope shots of the I2C bus?

We will analyze and double check it to see if there is anything we can figure out.

Thanks,

Nir 

Hi Nir,

The scope capture is fairly simple:

The data line is being held low.

The clock line is being held high.

Our MCU is seeing the clock line held high and abandoning writing to the bus.

Any thoughts?

Thanks,

Max

Hello Max,

Hmm, I was wondering how do we know that the PCA9548A holding the SDA bus low and not some other device downstream on the i2c bus? 

The key here is to figure out which device on the i2c bus is pulling the bus to a stuck low condition. It could be the PCA9548A , or a different device. 

The 9th bit (ACK) is the only time the PCA9548A is driving the bus low. Any other time, it is some other device communicating through the switch, or it is another controller device talking to the switch. 

Unfortunately, the only way to confirm it, is looking into scope shots. The PCA9548A would lock the bus low when it is driving an ACK signal from the device address. Any other time would be a different device locking it low, hence why a scope capture proving the 9th cycle is indeed locking the bus low would be helpful.

I Understand, since this event occurs after a month of operation it will be hard to get a capture. 

My suggestion is to monitor the system and if such an event occurs again, take scope shots and see what we can figure out. There isn't a way for us to prove what is the root cause of this issue without having captures. 

Again, I understand this is a big ask, but this is the best suggestion I have. 

Thanks,

Nir