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.

TUSB8044A: SMBus speed and reset

Part Number: TUSB8044A
Other Parts Discussed in Thread: TUSB8044

Dear team, 

1. At datasheet, I2C speed is 100K and 400K(default) and then, How about SMBus speed? Is it same with I2C speed? 

Please let me know maximum speed of SMBus interface. 

2. After changing internal register of TUSB8044A using SMBus, In order to re-configuration, Does the customer have to set smbusRst bit to 1 only or Is GRSTz reset needed?  

Thank you. 

  • Hi Dino,

    1. The maximum speed of SMBus is defined to be 100KHz by specification.  We have a helpful document that discusses the difference between I2C and SMBus called SMBus Compatibility with an I2C Device.

    2. If you change an internal register of the TUSB8044A using SMBus, and then issue GRSTz, the register will reset back to its default value.  The same behavior happens when using smbusRst as described in the datasheet: "SMBus interface reset. This bit loads the registers back to their GRSTz values".  In order to complete configuration, refer to section 8.4.4 of the datasheet.  You must clear the cfgActive bit in register 0xF8 to complete SMBus configuration.

    Regards,

    Nicholaus

  • Hello Nicholaus, 

    Thank you for your comment. 

    The maximum speed of SMBus is defined to be 100KHz by specification.

    1. Do you mean Host controller have to use max 100KHz datarate to change TUSB8044A internal register? If the customer use 400KHz data rate, Is it cause side effect? 

    2. I know when GRSTz  and smbusRst is set, the register will reset back to its default value

    What I am asking is the way of second configuration setting, After complete the first configuration as clear the cfgActive bit, Do I have to reset (GRSTz or smbusRst) to set the second configuration? SMBUSz(#39 port of TUSB8044A) is pull down status. 

    Thank you. 

  • Hello Dino,

    There are two interfaces in question: SMBus, which has a max speed of 100KHz, and I2C, which can be up to 400KHz.  This is defined by the specification, not just for the TUSB8044 and is true for every device.  Yes, you should only use 100kHz SMBus.  The 400KHz I2C interface is intended for loading EEPROM.

    1. A 400KHz SMBus signal is out of spec, and it should be reduced to 100KHz. 

    2. I see, sorry for the misunderstanding.  According to the datasheet, I would expect you can use smbusRst to reconfigure the device, but cfgActive is also required to be reset to 1.  There is no way to reset cfgActive after it's cleared, and so you should assert GRSTz to clear the old configuration, reconfigure all of the ports, and the set the cfgActive bit again.  

    Regards,

    Nicholaus

  • Hello Nicholaus, 

    Thank you for your comment. 

    cfgActive is also required to be reset to 1

    Do you mean cfgActive is also required to be reset to "0" not "1" ? 

    The bit is cleared by a writing 1 at datasheet, If this bit is cleared by writing "1" , What is the register value of cfgActive bit? "0" or "1"?? 

    At datasheet like below, please review below comment. 

    1. below comment (Red under line) , The TUSB8044A shall not connect on the upstream port while this bit is 1. Is it correct? 

    but green under line comment also said " this bit must be cleared by the SMBus host in order to exit the configuration mode and allow the upstream port to connect. The bit is cleared by a writing 1." 

    I think red comment is not correct. when cfgActive bit is "0", The TUSB8044A shall not connect on the upstream port. Is my understanding  right? 

    So There is no way to reset cfgActive to "0" after it's cleared("1"), we should assert GRSTz to clear the old configuration, reconfigure all of the ports, and the set the cfgActive bit again(set to "1").

    2. If my understanding is not correct and datasheet is correct, 

    - power on or GRSTz reset, SMBUSz,SS_SUSPEN D (#39 pin) pull down => enter SMBus mode, => cfgActive is 1, the upstream port is not connected => changing internal register => the SMBus host do clear cfgActive bit by writing "1" to exit configuration mode  => cfgActive bit is "0"  => we should assert GRSTz to enter SMBus mode to change internal register again. 

    Is above flow correct? 

    Please review my understanding and let me know your opinion which one (1 or 2) is correct. 

    Thank you. 

  • Hi Dino,

    The datasheet should always be correct.  If it is not, then it should be corrected. 

    I agree with you that the wording is confusing, but from the datasheet I would expect.

    1. cfgActive=1 by default after powerup and in SMBus mode
    2. cfgActive=0, when a "1" is written to the register (confusing, but the datasheet says this).
    3. cfgActive can only be reset to "1" by asserting GRSTz the TUSB8044.

    This matches with your option #2.

    Regards,

    Nicholaus

  • Hello Nicholaus, 

    Thank you for your confirm. 

    I have one more question. 

    After the SMBus host do clear cfgActive bit by writing "1" to exit configuration mode, we checked operation GRSTz and smbusRst. 

    we can see the result that cfgActive can also be reset to "1" by asserting smbusRst  the TUSB8044.

    Would you please check real operation of TUSB8044A using EVM or others? The customer would like to use smbusRst not GRSTz for second configuration. 

    I am sorry to bother you but please let me know your opinion whether the customer can use smbusRst not GRSTz to configure internal register.

    Thank you. 

  • Hi Dino,

    It's not a bother, thanks for the question.  Sorry for the confusion, I took another look at the datasheet, and I realized that I misread it.  After setting smbusRst to 1, the cfgActive bit is not also required to be reset to 1; it IS reset to 1.

    Datasheet: "Note, that since this bit can only be set when in SMBus mode the cfgActive bit is also reset to 1. When software sets this bit it must reconfigure the registers as necessary"

    It sounds like this is expected operation and there is no issue. You only need to set smbusRst=1 to reconfigure the ports. If you see any issues while using this method let me know, and I will reproduce it in the lab.

    Regards,

    Nicholaus