• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 4 answers
  • Subscribers 33 subscribers
  • Views 425 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

FPC402: SCL stuck for more than 300ms issue after hot-plug of SFP56

Zhigang Ding
Prodigy 10 points
Part Number: FPC402

Tool/software:

Hi team,

We are using FPC402 as SFP56 controllers.

And we have a hot plug design on SFP56: 3.3V on SFP is disabled in default and will be enabled after plug in( including PU on SCL/SDA ).

So after 3.3V power on, FPC402 downstream port's SCL will be stuck for 700ms. It's over 300ms (known as SFF-8431, t_2w_start_up)

Any explanation from your side? Is it reasonable on FPC402?

Thanks,

BR

Zhigang

  • 0
    TI__Guru* 93670 points

    Hi Zhigang,

    We haven't come across this issue before you reported this.

    1). Other than hot plug, FPC402 works in your application?

    2). Is the EN pin or device is enabled before you turned on 3.3V supply? 

    3). Any difference if device is enabled after you turn on 3.3V supply?

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 10 points

    1) Yes, this is an issue reported by our SW. Because 300ms expired and blocked initial sequence. But after 700ms, we can access downstream port

    2) Yes, EN pin is default on during plug in and SW initial

    3) based on answer of Question 2, i think no difference

    Any other suspecting?

    BR

  • 0 in reply to Zhigang Ding
    TI__Guru* 93670 points

    Hi Zhigang,

    1). Do i understand this correctly that if you wait for 700ms then you can access the device - once the device is in this mode?

    2). Would it be possible to have device disabled and enable it sometimes after 3.3V supply is turned on?

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 10 points

    1) Yes, plug in optical module and power on 3.3V. Then wait 700ms to access module

    2) Do you mean FPC402 reset? We are thinking the work around to have port reset between 3.3V enable and initial optical module. But Linux Kernel team isn't happy with that

    Besides, we have tried permanent 3.3V PU on SCL/SDA. There is no such issue. Any more idea here?

  • 0 in reply to Zhigang Ding
    TI__Guru* 93670 points

    Hi Zhigang,

    Since permanent 3.3V PU on SCL/SDA works, this means when I2C interface is exercised there is no pull up. This means we should enable PU much earlier within this 700ms time window. 

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 10 points

    Hi Nasser,

    Do you know what is the time delay requirement of FPC402 after 3.3V PU enabled?

  • 0 in reply to Zhigang Ding
    TI__Guru* 93670 points

    Hi Zhigang,

    From the supply being turned on the device to I2C access is about 20ms.

    Device does not know whether there is a pull up or not. But it checks for if I2C bus is stuck. By stuck i mean device cannot drive I2C signals - they are being pulled low or high externally.

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 10 points

    Hi again,

    Strange thing is here: FPC only need 20ms after power on. But our SW wait for 300ms after power on.

    This means SCL stuck happened and continue to 700ms and then recovered.

    So if you are suggesting we add a FPC402 reset(not port) after power on?

    BR

  • 0 in reply to Zhigang Ding
    TI__Guru* 93670 points

    Hi Zhigang,

    Does FPC402 AND SFP share the same 3.3V supply? I mean when you turn power on the SFP on hot plug the power gets turned on the FPC as well?

    Since permanent 3.3V PU on port side I2C works, it means somehow FPC device is not able to get acknowledgement and it times out. Is it possible to put scope on I2C signals to see what is occurring or what other entities could be driving the I2C lanes? There is a timer within the part that sets up the I2C stuck time out. Your FPC software driver could be setting up this register.

    Regards, Nasser 

  • 0 in reply to Nasser Mohammadi
    Prodigy 10 points

    Hi Nasser,

    Sorry for late reply.

    What register it is? And what is the default value?

    BR

  • 0 in reply to Zhigang Ding
    TI__Guru* 93670 points

    Greetings Zhigang,

    These are register 0x9B, 0x9C, 0xA1 through 0xA4. Please refer to the programming guide.

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Prodigy 10 points

    Hi again,

    I have checked, but i don't think it's the cause.

    Default time out is 10ms and will trigger a int to CPU. But this is not we want. We would like to see FPC402 recover by itself.

    And meanwhile it's far away from 300ms or 700ms.

    This timer counted in
    milliseconds and is 10 ms (typical) by default.

    root@hawkowl:~# i2cget -f -y 1 0x8 0x9d
    0x0a
    root@hawkowl:~# i2cget -f -y 1 0x8 0x9e
    0x0a
    root@hawkowl:~# i2cget -f -y 1 0x8 0x9f
    0x0a
    root@hawkowl:~# i2cget -f -y 1 0x8 0xa0
    0x0a

  • 0 in reply to Zhigang Ding
    TI__Guru* 93670 points

    Hi Zhigang,

    I agree with your statement. The thought was that maybe somehow this timer is getting set to a high value.

    To come around this issue, it would be a good idea to have scope shot when we have permanent 3.3V versus not permanent 3.3V on I2 C lanes. We should reference this scope shot with when we do FPC access to this XFP port. This could tell us what could be occurring here.

    Regards, Nasser