PCA9546A: PCA9548A

Hi Jason,

1. There are a lot of failures that could occur when using I2C are you specifically asking what are the common failures for the PCA9546A or I2C in general.
2. When you have finished your I2C bus you should test it to make sure that meets I2C spec for your desired speed.
   1. For the PCA9548A we show the tests that we preformed to make sure that the device is able to communicate correctly on SDA and receive SCL data correctly.
   2. We also test the RESET functionality 
   3. In general I would test all the timing functionality of the device, this includes I2C timing requirements, Interrupt and Reset timing requirements, and switching characteristics. This would be a good test to make sure that your bus and device are working correctly.

Best,

Chris

thanks, Chris

1. i am asking what are the common failures for the PCA9546A/PCA9548A  or I2C in general.

2. in addition to the timing functionality of the device,  what are the other stress test you would proposed ?  what is the test recipe ?  such as address deconflict, application where a higher capacitive load is required, multi-card application.

Jason,

1. We have a great app note about debugging common I2C issues. These are the general issues you will see with I2C. The only specific issue with the PCA9546A is the reset errata on the device. Section 8.4.1.1 goes over the reset errata in the datasheet. Essentially you have to make sure that the voltage on the RESET pin does not exceed the VCC voltage.

2. These devices are designed to handle specific I2C specs. So for this device it is compatible up to Fast mode (400 kHz). So for this speed we spec that the device can handle up to 400 pF. Anything in the datasheet characteristics we guarantee for the device. This means that we do our tests and if a device does not meet this spec we will not sell it.

For your other questions, you should not have two devices on an I2C bus with the same address. Each device should have a unique address or you could get issues communicating with the devices. The PCA9546A has address pins for this exact reason. They allow you to change the address of the device by pulling the pins high or low. If you have devices with the same I2C address on the bus you will have to use an I2C switch to be able to communicate with them individually.

When you say multi-card application are you talking about hot swap? If you are looking to design hot swap into your system you will need special hot swappable chips so that you can continue to communicate on the backplane.

The tests that you come up will have to depend on your specific system. The only generic tests you can preform are timing tests to make sure all the devices can communicate properly. For instance with a device like the PCA9546A you might want to test how quickly the device can switch between I2C channels, how many channels can be enabled at one time before the bus becomes overloaded. These questions will all come from your system requirements and will be specific to your set up.

Best,

Chris

chris, 1) for validation of diagnostic test purpose,   is there a way to simulate some hardware failure mode of I2C module/component for debug test purpose? 2) would you recommend a simulation tool or hardware device ?   3) what is the recommended hardware diagnostic tool /method to be used for I2C communication test ?  

Jason,

Chris is out of office right now, so we appreciate your patience while someone else on the team helps on this question. We will have a response to you by end of business tomorrow CST.

Regards,

Eric Hackett 

Hi Jason,

jason li said:

for validation of diagnostic test purpose,   is there a way to simulate some hardware failure mode of I2C module/component for debug test purpose?

This device doesn't have any kind of 'test mode', the device itself is just a state machine that runs off the a start condition,  clock pulses, and a stop condition. The only real failure I can think of given that is if you have a stuck bus event or a case where you don't perform a stop condition after writing to the device.

jason li said:

2) would you recommend a simulation tool or hardware device ?

If you're trying to test I2C 'robustness' you're better off testing on the bench rather than simulation since you likely won't have a FET level simulation tool. 

jason li said:

 3) what is the recommended hardware diagnostic tool /method to be used for I2C communication test ?  

Normally, you would just use a device that can generate open drain clock pulses and can switch between an output and an input on the data line (open drain as well when set as an output). Generally this can be done with a microcontroller/processor. A side from this, you could stress an I2C bus with an AC noise source to simulate noise or quickly connecting SDA/SCL to a small unpowered cap during operation to simulate a hotswap event. 

-Bobby