• State Resolved
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 88 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

DS160PR1601: why this part need 50ms before it can be read/write by I2C,

Chris Zhao1
Expert 1240 points
Part Number: DS160PR1601

Tool/software:

Hi experts,

I'm using ds160pr1601 in my PCIE path to boost PCIE signals for PCIE3.0 x8, and my board is installed in a PC.

in 20% of cases, 4 boards can only be recognized as GEN3 x2 at cold boot , after reboot they can link up to GEN3 x8; In 80% of cases they can link up to GEN3 x8 

I got 2 quesitons:

Q1,  I'm using a MCU to control I2C bus, but I can only get ACK after about 50ms, otherwise I can only get NACK, can you tell me why?

Q2, once configuration is done, will this re-driver function immediately,  or it has to wait some time? If so, how long will it take?

Regards

Chris

  • +1
    TI__Genius 12246 points

    Hi Chris,

    Thank you for reaching out about these questions.

    1. Please see data sheet section 6.7 regarding SMBus/I2C timing characteristics, field T_POR: https://www.ti.com/document-viewer/DS160PR1601/datasheet#GUID-XXXXXXXX-SF0T-XXXX-XXXX-000000317136/GUID-XXXXXXXX-SF0L-XXXX-XXXX-000000317136 
    2. The redriver will function immediately after ALL_DONE_N is asserted low in SMBus Primary/EEPROM mode, or immediately after POR in SMBUs Secondary Mode. When PDx pins are asserted low, the channels associated with each PDx pin will power on and triggers the PCIe RX Detect state machine.

    Do you know when the PDx pins are being asserted and if the PCIe Reset (PERST#) signal is de-asserted after redriver configuration is complete?

    Best,
    David

  • 0 in reply to David Waier
    Expert 1240 points

    Hi David,

    Thanks for your quick response.

    For 1, I programmed DS160PR1601 directly, so I was wondering it might be different from EEPROM Timing, in which the TPOR is 50ms.

    For 2, in my case, PDx are always being de-asserted, I found it should be toggled in Table 7-1 of datasheet, I can have a try and let you know. Fortunately I have some backup plane in my circuit. 

    What's the desired timing between PDx, PERST# and configuration? If PDx should be inverted of PERST#, can I still be able to do configuration during PDx is asserted.

    What if I set RX detect control register (offset 0x04) to 0x04, so it will continue doing Rx detect?  Any suggestion?

    Regards

    Chris

  • 0 in reply to Chris Zhao1
    TI__Genius 12246 points

    Hi Chris,

    T_POR holds true for both SMBus/I2C modes.

    Configuration of the redriver should be done before PERST# is de-asserted - as the EQ settings of the redriver will impact the signal integrity of the channels of the PCIe link. If PDx pins are tied to inverted PERST#, then this timing holds true. If toggling PDx pins manually, SMBus configuration should be done before toggling PDx pins low.

    EQ setting configuration can be done while PDx pins are high.

    Setting channel RX Detect register 0x04 = 0x04 will override the RX Detect block of the redriver. This would not continue performing RX Detect.

    Best,
    David

  • 0 in reply to David Waier
    Expert 1240 points

    Hi David,

    Thanks for helping.

    I think this issue is very clear, I'll move forward with inverted PERST# to control PDx. Bypass RX Detect is not a expected behavior for a re-driver.

    Regards

    Chris