This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PCA9545A: Compatibility issue with STM32, unable to open channel

Part Number: PCA9545A

1.STM32 can communicate with PCA9545A, can read and write the control register, the value is 0X0F,Can measure I2C input of PCA9545A, but no output.

2.Communication between LPC1768 and PCA9545A is OK.

3.The PCA9545A peripheral circuits of the two projects are completely the same.

  • Hello User,

    Can you provide SDA/SCL scopeshots for us to review?

    Typically with our I2C switches, the issue customers have when they can talk to our device but cannot talk through the device is because they are not providing a stop condition after enabling the channel. Our device will not enable secondary channels until it sees a valid stop condition.

    Can you verify that you are generating a stop condition after enabling the channel?

    Thanks,

    -Bobby

  • Hello Bobby

    1. This is the open all channel waveform

    2. This is the waveform of the communication downstream device, address 0x58

    3. tsps About 4.3 us

    Thank you for your answer.

  • user5899024 said:

    Hello Bobby

    1. This is the open all channel waveform

    2. This is the waveform of the communication downstream device, address 0x58 [Bobby] It looks like our switch device is working since this is downstream. The problem you stated earlier isn't that our device is not working, but the downstream device is not ACKing. Is this correct?

    [Bobby] Can you tell me where you probed the SDA line? I am wondering if we are looking at SDA from the master side or from the secondary slave channel side.

    3. tsps About 4.3 us

    Thank you for your answer.

    I added two questions above in bold.

    Thanks,

    -Bobby

  • 1. [Bobby] It looks like our switch device is working since this is downstream. The problem you stated earlier isn't that our device is not working, but the downstream device is not ACKing. Is this correct?

    Our MCU can read and write the control register, but the output from the slave side is always high, so the downstream device is not ACKing.

    2. [Bobby] Can you tell me where you probed the SDA line? I am wondering if we are looking at SDA from the master side or from the secondary slave channel side.

    SDA Schematic R1139,SCL Schematic R1140,Waveforms only on the master side

     

  • user5899024 said:

    Our MCU can read and write the control register, but the output from the slave side is always high, so the downstream device is not ACKing.

    [Bobby] I see. Thanks for the additional information.

     

    SDA Schematic R1139,SCL Schematic R1140,Waveforms only on the master side

     [Bobby] Can you take scopeshots at the slave's SDA/SCL pins. I'm wondering if our device may be shifting the VoL such that it is too large for the slave to recognize it as a low. (Rdson of the device may be affecting measurements)

    Can you also remove out device and short SDA/SCL from the master side to the slave's SDA/SCL to verify communication this way works?

    Comments again in BOLD.

    Thanks,

    -Bobby

  • Hi Bobby

    C1 R1139  C2  R1140  C3 U27.6  C4 U27.5

     

    Short SDA/SCL from the master side to the slave's SDA/SCL,Communication is OK.

    In addition,I did A-B-A swap test and checked,and checked the NXP and TI PCA9545 data sheets, but found no major differences.

    According to multiple tests, the output of PCA9545 is not turned on, and communication can be made only after replacing MCU with LPC1768.

    Please also confirm whether there is some compatibility issue between STM32F7 and PCA9545, can you help with the verification?

    Thanks,

     

  • Hey User,

    Can you try one more thing for me?

    It looks like you do not issue a stop condition after performing the write. I believe you need to do a stop condition immediately after the write instead of doing a restart condition.

    Can you give this a try?

    Try to do this same transaction but with a stop and then a read and have the scope probes hooked up like your latest one : C1 R1139  C2  R1140  C3 U27.6  C4 U27.5

    I'm guessing the other processor you used may have did stop and then start rather than a start and restart like the current one in this waveform analysis.

    -Bobby

  • Hi Bobby

    Thank you very much for your answer!

    The problem has been solved.