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.

DS250DF810: fail to access I2C

Part Number: DS250DF810

Hi, We have used DS250DF810 in 40G backplane application, here are 4 DS250DF810 on one board, ADDR are set to 0x30.0x32.0x34.0x36.

And we tied all DS250DF810's EN_SMB(E3) to 2V5, READ_EN_N(F13) is floating, ALL_DONE_N is floating, and 25M clock is chain from 0x30-0x32-0x34-0x36 by CAL_CLK_EN(E1) and CAL_CLK_OUT(E15).

Now we found sometimes serval DS250DF810 can't be accessed by i2c, when we access device's register 0xFC/0xFF, it returned 0xFF, but when we access register 0xF1, it can return 0x10 correctly.

The board is used by customer and we can't do any hardware test now, can you help us if here is any software debug methods or any reason can result this error?

Thanks a lot!

  • Hi,

    Are there specific retimer addresses or sockets that have this issue, or does it seem to be random.  Is there any activity or configuration you have correlated with this behavior?

    In general, this behavior seems unusual.  Are you able to access all global registers besides 0xFC/0xFF correctly?  When you observe the issue, are you able to write to 0xFC/FF and change it, or is it stuck at 0xFF?  Would you be able to share the value you get for these registers while observing the issue:

    • 0xEF
    • 0xF0
    • 0xF1
    • 0xF3
    • 0xFB
    • 0xFC
    • 0xFD
    • 0xFE
    • 0xFF

    Thanks,

    Drew

  • Our configuration will change 0xFC/FF, and it is stuck at 0xFF. And we can get a non-ack error at master when we configure the registers.

    Maybe it is held in reset? Is here any debug registers or software control register that can be used to determine the I2C reset status and force a reset release?

  • Hi,

    Do you only get a NACK from changing 0xFC/FF, or also other registers?  Is this correlated to specific devices in your system, or does it seem random?

    There is a shared register reset and channel register reset.  The I2C state machine reset is best controlled by the READ_EN_N pin though.  Since you are leaving this pin floating, the I2C state machine should not enter a reset condition.

    Share Register 0x04[6] controls share register reset.

    Channel register 0x00[2] controls the channel register reset.

    Thanks,

    Drew

  • We tried 0xFC/0xFF/0x00/0x78/0x27/0x28, these registers are all 0xFF, and it looks like a specific device, as it remains the same device after re-powering. 

    Are there any other test suggestions? As we have now left the customer's server room, it may take some time for us to have the opportunity to conduct experiments. At that time, we will try reading register 0x04 to see if it is in a reset state. If there is any progress, we will provide feedback here.

    Thanks

  • Hi,

    Are you able to conduct any I2C programming experiments remotely, or can you only conduct experiments in the customer's server room?  Is it possible to setup a log of I2C R/W that are being done?  I'm curious if there is any sequence that leads to this state.

    In general, it is unexpected that the retimer would somehow end up in a reset state where it's unresponsive to I2C.  I am wondering if there might be some sort of hardware issue.  I'd be happy to review a schematic of the system if you are able to share this.  You can share via E2E direct message.  I'd also consider checking pin voltages to make sure the hardware state matches expectations.  Is there any chance the retimer is receiving insufficient power?  You could also double check strapping resistor voltages.

    Thanks,
    Drew