Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 33 subscribers
  • Views 632 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

PCA9548A: I2C MUX Channel control.

Huang Derek1
Prodigy 50 points
Part Number: PCA9548A
Other Parts Discussed in Thread: PCA9543A, TCA9543A, TCA9546A

Hi,

    after I read the PCA9548A Spec, I know there is the register to help us control channels.

    when I set 7th bit and 2nd bit to on in PCA9543, are these bits on or off?

    if these bits are still off, I can use this one to tell I2C MUX is PCA9548, PCA9546 or PCA9543.

Thanks,

Derek

  

  • 0
    TI__Guru 62920 points

    Hi Derek,

    That's a good thought. I didn't think that the bits corresponding to unimplemented channels would reset automatically, but we will check further into the design in order to confirm. We will update you tomorrow.

    Regards,

    Max

  • 0
    TI__Guru 58860 points

    Hey Derek,

    I currently set an order to be shipped to me for the PCA9543A and TCA9543A to confirm whether or not bits 7 and 2 can be writable or if they are forced to be 0's even after a write occurs. I expect to receive the samples and be ready to test this around Tuesday of next week. I'll give you an update around that time frame.

    Thanks,

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 50 points

    Hi Bobby,

    thank you for spending time on this.

    I am looking forward to your information.

    Thanks,

    Derek

  • 0 in reply to Huang Derek1
    TI__Guru 58860 points

    Hey Huang,

    Just wanted to let you know, I received some samples of the device today. I'll look for some breakout boards or some kind of socket to test these units a little later and try to get back to you by the end of the day.

    -Bobby

  • 0 in reply to BOBBY
    TI__Guru 58860 points

    Huang,

    I was able to test the PCA9543A device. What I ended up doing was sending 0xFF to write to the device and read afterwards.

    Here is the first part of the transaction:

    You can see the first transaction shows:

    1) 0x70h (the address) with a write bit set and and ACK

    2) the following is a set of all 1's (0xFFh) and the ACK

    The second half of the transaction follows:

    1) start condition, address (0x70h), read bit set , and ACK

    2) bits received: 0011 1111 or 0x37h, then NACK (from the master)

    --ignore the following transaction----

    What we end up seeing is bits 0, 1, 2, and 3 are writable and readable (NOT MASKED)

    Bits 7 and 6 are AND'ed to be 0's are can't be overwritten.

    I've tested this by sending 0xF7h and reading 0x37h.

    As for the TCA device, I still need to find a socket/board to test with. One of the samples (PW package) I didn't receive yet. I'll let you know when it arrives or if I am able to find another board to try with the D package.

    Thanks,

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 50 points

    Hi Bobby,

    thank you for spending time on this.

    so, it seems like when the MUX supports 4 channels.

    there are only 0~3 bits to be written. rest of the bits are not able to be written.

    they are always 0, correct?

    Thanks,

    Derek

  • 0 in reply to Huang Derek1
    TI__Guru 58860 points

    Hey Derek,

    "so, it seems like when the MUX supports 4 channels.
    there are only 0~3 bits to be written. rest of the bits are not able to be written.
    they are always 0, correct?"

    That appears to be the case here:

    With the TCA9546A (I2C switch with no INT function), When I wrote 0xFF I read 0x0F.

    Bits 4,5,6, and 7 are all AND'd with 0's and are not writable.

    Thanks,

    -Bobby