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.

TCA9548A: Last byte latched when writing to Control Register?

Part Number: TCA9548A

Hello -

  I am working writing to the TCA9548A device using a generic i2c master interface, in which I transmit data in the order of: <SlaveAddr=0x70> <MemAddr=0x70> <DataByte=0x02>. I know that I don't need to send a separate MemAddr to this particular part, but I'm keeping this field intact so that this module is more generic for other applications in which I need a separate i2c memory address. The actual bus cycle is shown in the JPG below. Running SCL @ 400kHz.

  It looks like the TCA9548A is latching the MemAddr byte as the data, as opposed to the DataByte. This behavior conflicts with the datasheet which, on page 17 under Section 8.5.4 (Control Register) says that the last byte transmitted is latched as the data. All bytes are acknowledged by the Slave, so it doesn't look to be a data integrity issue. Am I doing something else wrong?

Blue:   SDA

Green: SCL (buffered on scope @ 3.3V)

  • Bryan,

    From looking at the picture, it looks like you're sending the following:

    111 0000 0 {0x70h} This means you are sending the device address and writing

    ACK

    0111 0000 {0x70h} data you write into the control register to select the channels... in this case channels 4, 5, and 6.

    ACK

    0000 0010 {0x02h} data you write into the control register to select the channels... in this case channel 2.

    ACK

    Based on the datasheet, last sentence of section 8.5.4 and 8.5.3.1 second to last sentence , it should activate only channel 2 once the master releases the SDA/SCL lines.

    Are you saying the channels you see turn on are only channels 4, 5, and 6?

    Can you send a read command to the TCA9548A? {0x71h} and post the o-scope picture?

    Are you also able to provide a schematic?

    Thanks,

    -Bobby

  • Hi Bobby -

     Thanks for your time & help on this ...

     As you suggested, it looks as if my issue may related to the way I'm reading from the device ...

     In regards to my initial post above, it looks like the true value being written to the Control Register is 0x02 ... I verified this by performing a write to the other side of the MUX, and seeing the traffic pass through (and only through) channel #1.

     I send the following sequence to read the Control Register from the TCA9548A (I know that the device only has one register, so no need to set the address before the read, but trying to keep the interface generic for various devices).

        <START>      <SlaveAddr=0x70; WRITE>      <MemAddr=0x70>       <RESTART>       <SlaveAddr=0x70; READ>      <ReadData=0x70>       <STOP>

     I've also sent enough transfers, with varying data, to see that the TCA9548A is returning the <MemAddr> value as the read data.  The device is acknowledging my transfers, but it's almost as if the initial transfer (to set the address for the subsequent read) is resulting in a write to the Control Register.

     I've posted a couple if scope plots below (sorry for the rudimentary screen captures ... scope only has 2.5" floppy as storage method).

     What am I doing wrong?

    Thanks,

     Bryan

  •  ... sorry - as far as a schematic - here's a shot of the relevant page for the device. It's a COTS HDMI board.

  • Hey Bryan,

    I believe I see the issue as to why you aren't reading the control register and seeing the last byte written to.

    The previous transactions you've made have all been write transactions and not read. Which shows why when you send 0x02, when you checked by sending data from all the channels, only Ch1 worked. But you could not read the control register properly.

    " I send the following sequence to read the Control Register from the TCA9548A (I know that the device only has one register, so no need to set the address before the read, but trying to keep the interface generic for various devices)."

        <START>      <SlaveAddr=0x70; WRITE>      <MemAddr=0x70>       <RESTART>       <SlaveAddr=0x70; READ>      <ReadData=0x70>       <STOP>

    This looks like a coding error. You are sending the wrong address to the device that you want to read from. Because you are sending a possible address and allowable data byte, you are receiving ACKs.

    EDIT: The slave address you should be sending to read from is NOT 0x70h but 0x71h.

    From the figure above, the LSB needs to be a 1 in order to read the control register.

    Lastly, your schematic looks fine. Wave forms show that the pull up resistors are good. You have minor coupling between your pink and blue wave forms though ( does not seem to present any signal integrity issues)

    One thing to note is Ch0 looks like it doesn't have pull up resistors, I am assuming they are there but not in the picture (but closer to other device). If not, you will need them inorder to communicate through I2C.

    Thanks,

    -Bobby

  • Hi Bobby -

    Thanks for this ...

    Just so I am clear - when I say the address is 0x70, I'm only referring to the upper 7 bits of the command. I am setting the Rd/Wr bit to '1' for the read transaction, and I think that's visible in the scope plot (do you agree, or am I off by a bit?)

    Thanks again,
    Bryan
  • Hey Brian,
    It looks like I've misunderstood your read/write naming convention here.

    Following your o-scope shot here:
    111 0000 0 <0x70h> Write to address 0x70h
    ACK

    0111 0000 <0x70h) data sent to control register.......Should turn on Channels 7, 6, and 5. Other channels should be turned off.
    ACK

    You then momentarily release SDA and SCL then re-initiate communications by pulling SDA/SCL.
    (this will turn on the channels as a result once the lines have been released)

    111 0000 1 <0x70h> Read from address 0x70h
    ACK

    0111 0000 <0x70h> Data read from the register is 0x70h......This is what we expect because you have previously wrote this value into the register.
    NACK -master tells the device to stop sending data and communication ends

    This is what I see from the o-scope shot. Though the SCL pulses are a little small and I may have made a mistake.

    This is what I expect the device to do so I am trying to understand the problem. Am I correct to assume the issue here is that you wish to keep the generic structure coding structure but want to keep control register on the device as the memory address and not the data? (from first post?) Or are you trying to confirm you are getting the correct read from the device?

    Sorry Bryan, I'm trying to fully understand what the current problem is so I can fully support you on this. From the first post, my understanding was, you thought the device was supposed to keep the last byte sent as the channels turned on and thought the device was keeping the second to last (memory address). From the second post, you were able to confirm the device was able to only turn on the second channel (Ch1) (your data byte). From there you wanted to confirm you could read from the device you just wrote to correctly. Is this correct?

    Thanks,
    -Bobby
  • Hi Bobby -

    Yea, I see it now. Stupid mistake ... obviously can't use the device in a RESTART scenario for reading, because I'm setting the Control Register in the initial write.

    Thanks for clarifying this for me ... I really appreciate your time!

    Regards,
    Bryan