HD3SS3220: HD3SS3220 Link bring up Test TD7.01.2 problem

Part Number: HD3SS3220

Tool/software:

Dear TI,

currently we made pre compliance USB tests at Granit River Labs. We use the Microchip Hub USB5708C and the TI MUX HD3SS3220 for the upstream facing port with USB Type C connector. The downstream facing ports are all USB Type A connectors.

Here we got a fail at the test for the upstream facing port.

TD7.01.2 Link Bring-up Test (Subtest 2): The PUT has transmitted more than 6 LFPS after receiving 1 LFPS while the Number of LFPS tx´d before receiving 1 > 18 - the Numer of LFPS tx´d after receiving 1. Gen 1 links should not do this to prevent conflicts with Gen 2 LFPS handshaking.

The downstream facing ports without the mux are working fine.

First i opened a case by microchip. But here finally i got this answer:

You also stated downstream ports are passing this test. Its the same PHY and behavior. the USB3 PHYs don't have any difference whether they are upstream or downstream. So that gives a strong clue that the mux is involved. What does TI say on the matter? I would recommend the customer also open a case to see if this is a known failure.

Do you know this issue with the mux?
Do you have a suggestion to fix this?

Attached is the schematic for the mux and the failure description.

Regards,
Manuel

  • Hi Manuel,

    Attached is the schematic for the mux and the failure description.

    Looking at the schematic you sent over, I see that it looks like the CC pins are flipped, I.E CC1 of the 3220 is going to CC2 of the connector, and CC2 of the 3220 is going to CC1 of the connector. Is this intended? This might be affecting the flip orientation of the HD3SS3220.

    Does the HD3SS3220 enumerate properly, I.E USB3 enumerating over the type-C connection? I want to ensure the device with the HD3SS3220 is able to properly communicate over the connection.

    Do you know this issue with the mux?
    Do you have a suggestion to fix this?

    This is not a known issue with our device, so I don't believe it is related to our device. Our mux also should not directly affect any of the data that is passed through, as it is just a typical passive mux. 

    Thanks,

    Ryan

  • Hi Ryan,

    thanks for you answer.

    First i connected the CC1 to the CC1 of the Type C connector, but then it doesn´t work correctly... After I switched it to CC2 it was fine. It works like expected.

    So the mux has no special USB modes or can shortly disconnect the connection between the input and output (except when disabled or the CC pins are switched)?

    Regards,
    Manuel

  • Hi Manuel,

    So the mux has no special USB modes or can shortly disconnect the connection between the input and output (except when disabled or the CC pins are switched)?

    Yes, correct. The HD3SS3220 does not have any special modes outside of active and shutdown, both of which are controlled by the EN pins.

    First i connected the CC1 to the CC1 of the Type C connector, but then it doesn´t work correctly... After I switched it to CC2 it was fine. It works like expected.

    Looking at the TX/RX pins in the schematic again, it does look like it is swapped, I.E TX1 of the HD3SS3220 goes to TX2 of the Type-C connector. That would explain why you had to swap the CC pins.

    Thanks,

    Ryan

  • Hi Ryan,

    am I right that the time from connected CC pins to settle the switch for the TX/RX Lanes are the tsw_on with max. 0.5µs?

    Could it be that this settling time can trigger this unintended behavior at the startup?

    Regards,
    Manuel

  • Hi Manuel,

    am I right that the time from connected CC pins to settle the switch for the TX/RX Lanes are the tsw_on with max. 0.5µs?

    Could it be that this settling time can trigger this unintended behavior at the startup?

    The time it takes to switch from TX1 to TX 2 is that time tsw_on, yes.

    Is the test being performed requiring the mux to actively be powered on and off, or flipping the mux orientation through the CC connection being disconnected and reconnected? Or is the test being performed all in one orientation?

    As long as the mux is powered and a CC connection is established before any test is performed, the mux should not have any effect. 

    I noticed this capacitor connecting to 5V on the ENN_CC pin. This is not needed, C160 can be removed. The ENN_CC pin can be directly connected to GND.

    Thanks,

    Ryan