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.

TUSB1310A: Intermittently Stays in Electrical Idle When Instructed to Go into Transmit Data Mode

Part Number: TUSB1310A

Summary:

I'm seeing this USB PHY Intermittently staying in Electrical Idle for about 4.2 ms after instructing the PHY into Transmit mode by changing TX_ELECIDLE to "0"  with TX_DETRX_LPBK=0 in Power State =P0.  Has anybody seen this issue or is it already a know issue in the TI PHY?

Details:

When the LTSSM is in Polling LFPS in USB 3.0, the PHY is in P0 with TX_ELECIDLE =1 and TX_DETRX_LPBK alternating between 0 and 1 (See Table 5-3: PIPE Control Pin Matrix).  Following satisfying the condition to exit Polling LFPS to go to Polling RXEQ, the PHY Power State is kept in P0 and TX_ELECIDLE = 0 and TX_DETRXLPBK = 0 to put the PHY into the Transmit Mode.  This works most of the times and the USB partners successfully train themselves with TSEQ, TS1, and TS2 patterns, ending up in U0.  However, intermittently, every 10 to 50 times resetting the USB device, that has the TI TUSB1310A PHY, I see a scenario in which the TI PHY gets stuck in Electrical Idle when it is instructed to go into Transmit Mode.  This condition lasts for about 4.2 ms at which time I see either TS1 or TS2 patterns on the TX+- Differential Drivers lanes, i.e., the entire TSEQ pattern provided by the MAC to the PHY is missed and most or all of TS1 patterns are also not seen on the TX+- lanes, which results in unsuccessful operation of the USB partners getting into U0.

I'm assuming, according to the PIPE Spec, that the change of the "modes" in the Power State =P0 can be immediate, and hence, the change in TX_ELECIDLE and TX_DETRX_LPBK (and, hence, the Idle and Transmit Modes) are not qualified in my MAC in any way (like PHY_STATUS) except the LTSSM state's need to move from Polling LFPS to Polling RXEQ.

Has anybody ever seen this issue or is this a known issue in the TI PHY?  I have trace captures from the failing condition that I can share, but it is pretty much what I have described above.  Does anybody have an idea why the Electrical Idle (failing) always takes about 4.2 ms? Is this related to the PHY Transceivers in the TX Differential Driver not turning on for some reason?

Thanks!

  • Hello Mohsen,

    We will check your question.

    Thanks,

    Gerardo

  • Hi Gerardo,

    Thank you for looking into this issue!

    I've looked into the possibility of TI PHY RESET handling contribution towards this issue.

    Currently, our USB device resets has the following components. Can you please confirm the steps are correct?

    1. RESETN is released sometime (few ms) after the voltage and input clock into the PHY is present (follow Figure 5-1 in the TUSB1310A Datasheet)

    2. OUT_ENABLE is enabled sometime (few ms) after Step 1 (Not following Figure 4-1 that we have interpreted as a "recommendation" for OUT_ENABLE - Please confirm this assumption as well)

    3. PHY_RESETN is released sometime (few ms) after Step 2 (follow Figure 5-1 and we have assumed "Internal resetn" is the same as RESET# in the PIPE Spec - Please confirm this assumption as well)

    Also, I came across this case (https://e2e.ti.com/support/interface/digital_interface/f/130/t/534276 ) that the final parts of which has been dealt with in email communications. Is there information you can share from that case please?

    Thanks,

    Mohsen

  • Hello,
    Can you share the trace captures? I'm wondering if you are trying to do an invalid state transition, there are a set of valid state transitions, for example, you can't go from P2 to P3.
    Are you doing some kind of stress testing?
    Is the TUSB1310A working fine whenever the issue is not present?
    Do you have failing and passing boards? If so, can you swap the TUSB1310A to see whether the failure follows the part?

    Regarding your questions:
    OUT_ENABLE; I do have a concern here, I'm thinking whether the FPGA is latching an invalid value on the PIPE since the TUSB1310A is still in reset, can you tie OUT_ENABLE and RESETN together?
    You also have to ensure all the strapping pin options are set before the de-assertion of RESETN.

    Yes, this PHY_RESETN is the same as RESET# in the PIPE spec.
  • Hi Elias,

    Thanks for the feedback.

    I can surely share the trace. How can I send you the trace?

    Re invalid state transition, I don't believe that is the case. It is the same code that works for all other cases except for the failing case that is seen every so often after a PHY reset. Also, I have captured the internal FPGA logic timing diagram and the failing condition is the same as expected and seen in normal operating condition.

    Yes, this is a "stress" testing of some sort, where by, the device is reset many times over.

    The PHY works fine when the error condition is not seen. The failing condition happens every 10 to 50 times resetting the USB device.

    All our devices with the TI PHY exhibit the same failing. We have tested multiple of our devices each having its own TI PHY.  Hence, we don't have "passing" and "failing" boards.

    On the OUT_ENABLE, we have already changed that to match Figure 4-1 in the TUSB1310A Datasheet and we did not see any change in the failing performance.

    All the strapping pins are set in the hardware and there is no change to them.

  • Hi Elias,

    On strapping and the use of RESETN and OUT_ENABLE, as I mentioned in my previous post, we have not seen any impact on the issue of this case when we drive OUT_ENABLE high before or after driving the RESETN high (both starting as low).  

    However, I have another question for this re dynamic strapping of XTAL_DIS instead of the static method we currently have.  In our next design we are going to driver XTAL_DIS from a register on the FPGA.  What is the strategy TI is suggesting for the relation between the tri-state input of the FPGA pin, the RESETN, and the OUT_ENABLE such that we avoid a)contention and b) race condition?

    We are thinking to do these steps in sequence:

    1. The tri-state input of the FPGA pin connected to the XTAL_DIS (RX_ELECIDLE) is by default programmed to have this pin as output from the FPGA to the PHY. We drive required value to the XTAL_DIS for strapping. RESETN is low in this step

    2. Assert the RESETN high ensuring XTAL_DIS is sampled to the desired mode driven from the FPGA register

    3. Change the tri-state input of the FPGA pin to program it as input ready to receive RX_ELECIDLE

    4. Assert the OUT_ENABLE high to activate the RX_ELECIDLE 

    5. Assert PHY_RESETN to high to start the PIPE interface

    Would the above steps be sufficient for correct behavior?

    Thanks,

    Mohsen

  • Hello,
    I apologize for the delayed response.
    Your sequence looks correct.
    The XTAL_DIS pin has an internal PD which is active all the time, so the tri stated FPGA should not pose a problem.
    I will run this question with the Design Team just to double check.

    Regards
  • Hello,

    The Design Team thinks your sequence is correct as well.

    Regards

  • Thank you Elias for the confirmation.

    Is there any update on the original issue of this case?

    Cheers,

    Mohsen

  • Hello,
    Can you disable the SSC on the TUSB1310A?
    Regards