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.

TUSB8041: Compliance Mode Testing

Part Number: TUSB8041
Other Parts Discussed in Thread: TUSB522P

Customer is trying to perform some compliance testing with the TUSB8041 HUB.

The setup has a Host connected to a TUSB8041, and the downstream ports of the TUSB8041 connect to another TUSB8041, which connects to some Type-A receptacles.

They are having trouble getting either of the upper or lower hubs to enter compliance mode.

Equipment: J-BERTM8041A

Software: N5990A、M8070A

The settings for N5990A are as follows:
- Configure DUT > Parameters > Loopback Training (from Rx 5Gb/s tab) > "PowerOnReset" & "PoweronReset LTSSM" were both tested

Any tips/advice/documentation/etc on how to go about getting the TUSB8041 into compliance mode?

Regards,

Darren

  • Hi Darren,

    For the test, can you confirm that the USB host upstream of the hubs has enumerated the hubs and is not resetting them during the test?  We recommend that the XHCI HSETT tool be used if this is a windows based system since it allows for enumerating the bus, but then the driver does not act on the ports until another command is generated by the tool.

    Regards,

    JMMN

  • Hi JMMN,

    Am I understanding this correctly?

    [1]
    xHCI HSETT tool is only used to get the DUT into compliance mode - the actual measurements are done with other hardware/software.

    [2]
    I'm understanding the tool works for Compliance testing on the Tx-side, but is there anything you need to do to test the Rx-side?

    [3]
    You mentioned " ...is not resetting them during the test?" above. 
    But for the Rx-side, my customer says they need to Power OFF/ON the DUT as part of the test process...
    Could you help clarify this point a little?

    Thanks!

    Darren

  • HI Darren,

    1./2. I was recommending that the customer load XHCI HSETT, not to use it set compliance mode, but to use its driver.   If you load XHCI HSETT and enumerate the bus, the driver doesn't do anything else whereas regular operating systems tend to go out investigate port status changes and reset ports when they go to loopback or compliance mode.  In this case, I'm suggesting using XHCI HSETT for what it doesn't do rather than what it does do.

    3.  Yes, powering off/on the hub is required as part of the test, but if the hub is getting a complete warm reset from the host that will impact test results and the ability of ports to go to loopback.

    Can the customer adjust the amplitude of the loopback signal input to see if that helps the hub port go into loopback?

    Can they share any screenshots of the test?

    Regards,

    JMMN

  • Hi Julie,

    They tried running the HSETT (just running so the driver is loaded, not actually using any of the app features), but didn't see any changes.

    I have some setup images and waveforms, if you could check?

    Darren

  • Yes, I will review the data and respond tomorrow.

  • Hi Darren,

    The bottom left hand side waveform is the port in polling.  It would get stuck in polling if it has successfully completed polling at least once since its last reset / power cycle event.  To enter compliance mode requires polling to timeout and never have succeeded since the last reset / power cycle event.

    The lower right hand side waveform looks like the port is in compliance mode and getting into loopback.  The lower amplitude is expected.  I'm sharing the system settings that were used recently in our lab.

    Regards,

    JMMN

  • Hi Darren,

    Any update here?

    Regards,

    JMMN

  • Hi JMMN,

    They had to work on another evaluation aspect and said this might take a month to get back to.

    I should have an update by end-of-July.

    Darren

  • Hi Julie,

    I have an update - and need your help again.

    [1]
    Can we share any Rx Compliance Test Report for TUSB8041I? 
    Offline?

    [2]

    Can the customer adjust the amplitude of the loopback signal input to see if that helps the hub port go into loopback?

    They tried using a special piece of equipment that emulates insertion loss, to "simulate" a 3[m] cable connection.
    With higher insertion loss (greater attenuation) on the trace, the setup enters Loopback most of the time.
    Without this attenuation / insertion loss, they hardly ever enter Loopback.

    They believe this might have something to do with the LFPS signaling amplitude?
    This E2E Post seems to discuss something similar - can you share how this was resolved? Or any other thoughts?

    [3]
    Is there a minimum required "insertion loss" or "de-emphasis" or "attenuation" required...? (a.k.a. MIN trace length?)
    This is asked because we see a stronger attenuation (insertion loss) giving a higher chance to enter Loopback.

    [4]
    The USB3.2 spec also mentions in Table 6-18 "VTX-DE-RATIO" of 3.0 ~ 4.0 dB de-emphasis for transmitter...
    It also says for loopback you can't just connect Rx and Tx, you need a re-timer.

    I see they have TUSB522P in between the TUSB8041I and the Type-A SS connector...
    I will send some schematics offline if you could check...?

    [5]
    They were hoping to get an opinion on some PCB layout choices, but I only have a .tgz zipped file for ODB++? Not sure how to import into Altium...would you want to see this too?

  • #1/#5 - I'll answer via direct email.

    #2.  We have seen issues with the hub not going into loopback because the amplitude was too low, not too high.  This behavior may be caused by the redriver, are they seeing it on all ports or just the one with the redriver?

    #3. There isn't a minimum insertion loss budget.  It is possible that the attenuation is actually attenuating some noise or overshoot that is causing issues.

    #4. The spec statement about not being able to connect RX and TX directly refers to the loopback connection within the DUT.

    One thing I did want to correct is that the TUSB8041 should NOT be in compliance mode for entry to Loopback.  If the hub enters compliance mode, it prevents entry to loopback.  Compliance mode is for TX testing, Loopback is for RX testing.  

    The TUSB8041 is an older hub design and is compliant to an earlier version of the USB 3.x specification.  This should not impact the actual test results, but it does impact the compliance mode entry, which could be preventing loopback entry.  Originally downstream ports of hubs automatically entered compliance mode if they failed polling.LFPS after a power on reset if they had never made a successful transition to U0. 

    This entry to compliance mode on the downstream ports can be prevented in two ways: 

    1. After the hub is powered on, connect the upstream port of the hub to a USB 3.x host and connect a USB 3.x device on the downstream port to be tested and remove it.  Once the downstream port has had a successful transition to U0, the port will not enter compliance mode until the hub has been reset / power cycled.
    2. If accessible, there is a register bit in the TUSB8041 that will prevent downstream port compliance mode entry unless directed by a USB command, it is bit 2 in Register 0Ah (dsportecr_en).