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.

DS125DF111: SMBUS ADDR and DONE FUNCTION

Part Number: DS125DF111

I am using the DS125DF111 in an application that boots from an EEPROM and then should switch to SMBUS SLAVE mode per the datasheet. I have the ENSMB pin (pin 3) floating and I have my SMBUS address set as 0x34 which ties pin 10 (ADDR1_VODB_DONE_N) to VCC. I have found that any pullup on pin 10 (1k, 22k,51k) will cause the device to not boot properly from the EEPROM. I have also tried setting the SMBUS address to 0x36 but again the pullup on the DONE pin causes the device not to boot from EEPROM. I can remove these pullups to allow the device to boot from EEPROM successfully but then I can't communicate over the SMBUS because the address is invalid. Can you advise why I cannot set the SMBUS address to 0x34 or 0x36 and still boot from an EEPROM?

  • Hi Joe,

    Can you clarify the device behavior when it does not boot properly from EEPROM?  Is there no attempt made to read the EEPROM when ADDR1 is pulled high?  Can you also verify that READEN (pin 9) is pulled down to GND?

    Thanks,

    Drew Miller

    HSSC Applications Engineer

  • I can verify that pin 9 (VODA_READEN_N) is pulled to ground with a 1k resistor. The behavior of the device when the SMBUS ADDR is set to either 0x34 or 0x36 is that there is no CDR lock and hence only noise at the output from the device. It also appears the internal registers are being setup incorrectly when viewed with the SIGCON gui. I can use the SIGCON gui to reset the device and then program the registers manually and it will work so it seems the EEPROM read and subsequent internal register setup is affected when the DONE pin is high at boot. Alternately, if the SMBUS address are 0x30 or 0x32, everything works fine, EEPROM programming SMBUS communication. It is only when the done pin is pulled high at boot that the issue arises. 

  • Hi joe,

    It seems like, if the SMBus Master Mode EEPROM programming procedure works for retimer slave addresses 0x32 or 0x30, that there must be some hardware setup issue or SMBus conflict on your side.

    Regards,

    Rodrigo Natal

    HSSC Applications Engineer

  • Correct, there is a hardware issue with the TI chip in which it seems it cannot be used with addresses 0x34 or 0x36 and still boot from EEPROM. I would be happy to share my schematics with you for review if you feel the issue is on my side. Have your hardware engineers tested this exact scenario on the eval board TI provides?

  • Hi Joe,

    TI validated the retimer Master Mode programming procedure with multiple ADDR pins configurations and confirmed that it works.

    We suspect that there may be an issue with the HEX file that you are using. Specifically, in order for the Master mode programming procedure to work valid address map header data must be implemented in I_SMB_ADDR locations 2 and 3. For a device with address 0x34 or 0x36, you must have a valid address map header in the offset location. Please refer to table 4 of the TI application note per link below.

    https://www.ti.com/lit/an/snla245/snla245.pdf

    Thanks,

    Rodrigo Natal

  • Rodrigo,

    Thank you for the explanation. I understand the issue now. I failed to recognize that each SMBUS address had a set starting point for the address memory map locations.