• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 34 subscribers
  • Views 2156 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.

TCA9544A: Questions for I2C MUX

Jim CHEN
Expert 4795 points
Part Number: TCA9544A

Dear Team,

A platform takes I2C MUX TCA9544APWR to connect to Skylake SOC I2C port, and three I2C devices are located under the MUX.

Some questions would need your help.

1. Does the MUX device require a Windows device driver for enabling? Or we only need to install Intel Skylake Win7/Win10 I2C drivers?

 

2. We plan to have unique ID stored in each bay EEPROM, BIOS would need a way to read the IDs from attached bays for recognizing which devices inside of the bays are attached.

This is the way what we proposed and I’m interested on the mechanism to sync up EEPROM of bays to MUX EEPROM if it’s true.

If it’s not, would you please share the way for BIOS to read the IDs through MUX?

BIOS would set selection bit to enable each channel at a time (for detail please refer to below SPEC), after the channel is enabled, the EEPROM data on wireless bay would be synchronized with the EEPROM on the MUX, then we can send smbus command to read data from EEPROM on MUX to recognize which device is installed on each channel.

 

3. The I2C devices attached to MUX will have the same address as a result the modules will all be built with same I2C address devices.

Is there concern on the same slave address attached to the different I2C ports of MUX?

4. Would you please send me MUX datasheet for reference.

Thank you.

Regards,

Jim

  • 0
    TI__Guru 57750 points

    Hey Jim,

    1. We provide analog support for our devices so software questions are usually outside our expertise though I will try to answer your question to the best of my ability. Our device does not look at what the software driver is, all it is looking for is a start condition followed by an address (with a R/W' bit) and an internal register address then data and a stop condition (assuming a write command). If you can accomplish this with a driver, then it does not matter what driver you use. Any driver will work so long as the master can use it properly.

    2. "BIOS would set selection bit to enable each channel at a time (for detail please refer to below SPEC), after the channel is enabled, the EEPROM data on wireless bay would be synchronized with the EEPROM on the MUX, then we can send smbus command to read data from EEPROM on MUX to recognize which device is installed on each channel."

    Our I2C MUXs do not have a selection bit, but an address. The master would need to send the device address of our TCA9544A then write to the internal address to enable the channel. If your RF Bay device has the same address as the others then only one channel can be enabled at a time. After a channel is enabled, you would then be able to communicate to your RF Bay device to read the ID and send or retrieve data. Afterwards you would then need to disable the channel and enable the next channel.

    What the customer suggested seems like it would work from an analog standpoint.

    3. Is there concern on the same slave address attached to the different I2C ports of MUX?

    I am not sure I completely understand the question. If the MUX has a different address then the I2C devices then there will be no address conflict. If the channel is enabled and there is another device with the same address on the I2C bus then there will be an address conflict. The customer would have to check all the addresses to make sure this does not occur. If the channel is disabled and there is another device on the bus with the same address then there is no conflict because the channel is disabled.

    4. "Would you please send me MUX datasheet for reference."

    Sure.

    Thanks,

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 30 points
    Hi Bobby,

    Thanks for helping on the Jim's case.
    The system hardware design is connect TCA9544A I2C MUX to a SOC I2C port and multiple I2C devices are behind the MUX on different channels.
    Regarding to #1, the SOC chipset is Intel Skylake and the OS environment is Windows (Win7 and Win10), the Windows image will install Intel serial I/O driver to enable chipset I2C support for the MUX. I'm wondering to confirm if the MUX device works with Windows inbox driver which means no need to install a extra driver to enable the MUX on Windows, or a MUX driver is available and required to be install on Windows image?
    Regarding to #3, multiple I2C devices are behind the MUX on different channels and the devices will be all enabled at the same time. We consider no I2C conflict as the devices are in different I2C segments (channels) behind the MUX. Would you please confirm again?

    Thank you.

    Best regards,
    Jill Hung
  • 0 in reply to Jill Hung
    TI__Guru 57750 points

    Hey Jill,

    "I'm wondering to confirm if the MUX device works with Windows inbox driver which means no need to install a extra driver to enable the MUX on Windows, or a MUX driver is available and required to be install on Windows image?"

    -I am not familiar with the windows drivers (or software). What I can say is if the driver you are using is open drain and can read what the state of the I2C bus is then it should work. All it has to do is be able to supply a start condition, 7 bit address with a read/write bit and be able to see an ACK. Afterwards, you can write to the registers and then supply a stop condition.

    "We consider no I2C conflict as the devices are in different I2C segments (channels) behind the MUX. Would you please confirm again?"

    -Yes, from the information you have provided as long as there are no address conflicts then the device will work. You can have as many I2C devices on the channels are long as there are no address conflicts and you do not exceed the I2C maximum bus capacitance allowed.

    Thanks,

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 30 points

    Hi Bobby,

    Thanks for help.

    For Windows driver, I believe system enables standard I2C interface for the I2C MUX device.

    For I2C conflict concern, I would like to clarify it a little bit more. We attach three I2C devices behind the MUX on different channels, and the three devices will be enabled at the same time. If the three devices are assigned the same slave address, is there I2C conflict concern?

    Best regards,

    Jill

  • 0 in reply to Jill Hung
    TI__Guru 57750 points
    Hey Jill,

    "For Windows driver, I believe system enables standard I2C interface for the I2C MUX device."
    -If that is the case, then you should be fine.

    "If the three devices are assigned the same slave address, is there I2C conflict concern?"
    -Yes there is now an I2C conflict from what you described because all three channels are enabled, there are now three devices with the same address connected to the main I2C bus. You need to only enable one channel at a time.

    Now... if you had the three channels enabled and the master was only doing a write then this COULD work but a read would result in a potential to corrupt the signal integrity of the I2C line. (3 different slaves with the same address are all trying to talk but if each one tries to say something different then the signal integrity is now in question). We still advise you to not enable all 3 channels even if you are just doing a write command as you are no longer following I2C standard.

    Thanks,
    -Bobby
  • 0 in reply to BOBBY
    Prodigy 30 points

    Hi Bobby,

    Thanks for response, however, to eliminate address conflict is the exact purpose of choosing TCA9544A, it's stated in the datasheet.

    Or when we connect multiple temp sensors with the same address under the I2C MUX, multiple channels should NOT be enabled at the same time defined in 9.6.3 Control Register?

    If yes, in system POST, BIOS owns to select one channel at a time, who owns the operation to select one channel at a time under OS? Would you please clarify it?

    Best regards,

    Jill Hung

  • 0 in reply to Jill Hung
    TI__Guru 57750 points

    Hey Jill,

    "when we connect multiple temp sensors with the same address under the I2C MUX, multiple channels should NOT be enabled at the same time defined in 9.6.3 Control Register?"

    -This device does not allow for multiple channels to be enabled at the same time as it states in 9.6.3 that only one channel can be selected at a time.

    "when we connect multiple temp sensors with the same address under the I2C MUX, multiple channels should NOT be enabled at the same time defined in 9.6.3 Control Register?"

    -You are correct, you should NOT enable multiple channels at the same time if they have the same address. This device does not let you do that because it only allows for one channel to be on at a time anyways.

    Thanks,

    -Bobby