TUSB1002A: How to use two TUSB1002A in series?

I'm sorry that I didn't reply to your previous message. You asked for a block diagram:

Host --> 2-meter USB-A to USB-B cable --> MyBoard --> 1002A (<1" from Type-B connector) --> Isolator IC (<0.5" from 1002A) --> 1002A (<0.4" from Isolator) --> Type-A connector (<1" from 2nd 1002A) --> 2-meter USB-A to USB-B cable) --> Device

The reverse path from Device-to-Host is the same. The problems I am having is the failure for Windows to recognize the device through the two 1002A and Isolator IC path reliably. I have sent 5 prototypes to our customer and they had no issues. I'm not sure why I have a few computers that don't recognize any device through this path. We have tried using the EQ and VoD settings. The system appears to pass our compliance testing (host-to-device only).

Any other suggestions we should be looking for?

I've got a few more questions to get a better idea of the problem

Jeffrey Kleck said:

The system appears to pass our compliance testing (host-to-device only).

From this description it sounds like the TX channel (Host --> device) is working. Have you tried adjusting the EQ settings on the RX channel (Device--> host)?

Additionally can you see anything when passing a signal through the RX channel (Device --> Host)? 

Jeffrey Kleck said:

I have sent 5 prototypes to our customer and they had no issues.

It sounds like the prototypes you sent are able to detect the device from a computer through the isolation barrier. Have you tried using a different device or a different Host PC? Maybe there is an issue with the specific device you're testing with.

Was there anything different between the prototype board you sent and the board you're currently testing on? This might tell whether there is a board specific issue.

Best,

Shane

Shane,

I have two concerns with the two 1002A in series with our isolation device and I believe they are somewhat related:

1. The 1st 1002A is powered from the host 5V input via 3.3V LDO. The 5V from the host is applied to an isolated 5V-to-5V power supply that in turn powers the 2nd 1002A through its isolated 3.3V LDO. I will have to measure the delay from 5V from the host to 5V to the device, but could this delay be too long that the host has already given up on USB enumeration before the downstream device is even powered? Could we hold off the 1st 1002A in each direction, so it doesn't turn on its RX termination and start the enumeration process until we know that the 2nd 1002A is powered and ready to see this upstream RX termination? Same issue from device --> host. Does this process of sensing termination on TX outputs to turning on termination on RX inputs continue until the host senses termination on its TX pins?
2. Similar to the aforementioned delay, could the enumeration from the host be starting before the 2nd 1002A and/or device downstream is ready to receive it? Does this whole process of 1st 1002A sensing termination by the USB host on its TX pins, to device turning on its RX termination and back to the host sensing termination by the 1st 1002A on its RX pins take place before enumeration process even starts?

Why do I ask? It is because the Passmark USB 3.0 tester does state that the system is enumerated when a device is plugged into the USB isolator, but it doesn't complete the entire enumeration process. The Passmark USB 3.0 tester says its enumerated, but it doesn't go active and display the proper speed. It seems to hang in the power-up sequence somewhere on the host side. On the host-side, it doesn't show any device active on the USB port. What is the final step in this power-up sequence required for the Host to recognize a valid device is attached to its USB port? Looking at the USB 3.2 specifications, it appears that something triggers the final state change from enumeration to active state.

Regards,

Jeff K

Shane,

If I do want to delay the enable to the 1st 1002A, how much variation is there in the Rpu resistor on the EN input? Datasheet only specifies typical of 400k. What is the minimum resistance?

Hi Jeff,

Jeffrey Kleck said:

What is the minimum resistance?

The 400K pullup metric is the internal pullup on the EN pin inside the 1002A. This means if you leave EN no-connect, there will be a 400K pullup inside the device to drive EN high.

I'm not aware of a minimum resistance on the EN pin. We typically recommend a 4.7K pullup if you want to drive the pin externally.

1. 

Jeffrey Kleck said:

Does this process of sensing termination on TX outputs to turning on termination on RX inputs continue until the host senses termination on its TX pins?

Short answer: Yes

Long answer: The 1002A will continuously check for RX terminations on the TX pins while in disconnect mode. For our device, this is the case until terminations are detected on both channels (TX1 and TX2). Once terminations are detected, the 1002A will enter active mode and pass signals through both channels.

A USB host will also continuously check for terminations on its TX lines. 

2.

Jeffrey Kleck said:

could the enumeration from the host be starting before the 2nd 1002A and/or device downstream is ready to receive it?

This is unlikely, the host will not begin enumerating until RX terminations are sensed on the TX lines. The RX terminations of the first 1002A will wait until it sees RX terminations from the second 1002A. I drew a diagram to show the RX detect process with chronological steps (1 = first, 2 = second,...):

3.

Jeffrey Kleck said:

What is the final step in this power-up sequence required for the Host to recognize a valid device is attached to its USB port?

The enumeration process happens in these steps: RX detect --> LFPS --> Training --> active mode. Do you see LFPS through both 1002As when terminating the tx lines?

Best,

Shane

I will need to get some scope captures, but it appears that we see a series of LFPS chirp cycles, but the 1st one doesn't look very good and sometimes stops the LFPS cycle and the system stops. That's why I was wondering what happens if this LFPS cycle (training) begins before the device power supply is ready.  Other than holding off the upstream 1002A with RC on the enable pin, I don't believe the in-series USB isolator can control what the hosts does. Similar to the block diagram you sent showing the steps from Device-to-Host for RX detection, I assume simultaneously the host has its RX terminations always enabled so begins the host-to-device RX detection starting with the 1st 1002A sensing termination on its TX outputs and enabling its RX termination on its inputs, then the 2nd 1002A sensing termination on its TX outputs and enabling its RX termination on its inputs, finally then the device sensing termination on its TX outputs will complete the upstream connection. Correct?

Just not sure why I am having such a difficult time connecting different devices to different hosts with the in-series USB isolation.

Hi Jeffrey,

Jeffrey Kleck said:

I assume simultaneously the host has its RX terminations always enabled

That is correct.

Jeffrey Kleck said:

I was wondering what happens if this LFPS cycle (training) begins before the device power supply is ready.

LFPS will not begin until RX detection is successful. RX detect will not be successful until both 1002A devices have power and enable their terminations. This means the LFPS should not begin before both 1002A power supplies are ready.

It sounds like you are able to get to the LFPS, but there is a chance that the LFPS signal looks bad, which kills the connection. Can you share the waveform for the good (LFPS keeps polling) vs bad (LFPS stops polling) signal?

Another question. Does the LFPS cycle only stop on a certain USB host, or is this the case for all USB hosts you've tried?

Best,

Shane

What scope captures do you need?  Super-speed host-to-device or Super-speed device to host or both?

It would be good to see both:

The SS host to device LFPS at the device location

The SS device to host LFPS at the host location

Best,

Shane

I am awaiting the new PCB assembly to be built before I can get scope captures. I will re-open case if I still have issues with the new assembly. Thanks.

Hi,

Thanks for the update, I will close this thread for now. You can submit a new E2E thread or re-open this one.

David