HD3SS3212: USB-C IP67 Interface not working as USB 3.0

Timoteo

How do the USB1_TX_DN_P/N and USB1_RX_DN_P/N being connected?

Thanks

David

Hi,

Attached the circuit for the USB hub. As mentioned before, the other 3 USB components run at 3.0 without issues.

Regards,

Timoteo

Timoteo

Please replace C117 and C122 with 0 ohm resistor since you already biased on the other side of HD3SS3212.

If the device is still not being recognized, would you please probe on TX and RX to see if LFPS is present?

Thanks

David

Hi,

Thank you very much for your response.

The device is still not recognised after removing C117 and C122.

Probing the TX lane, this is what I can see after Linux boots.

Channel 1 is TX P

Channel 2 is TX N (INVERTED)

The white signal is the sum of CH1 + CH2 (inverted)

Regards,

Timoteo

Timoteo

Are you measuring at the output of the hub or the output of HD3SS3212? The LFPS should typically be around 20MHz, not 60Hz as shown in the screen capture.

Thanks

David

Hi,

At the output of the hub, where C117 and C122 were.

Best regards,

Timoteo

Timoteo

Did you replace C117 and C122 with 0 ohm resistors?

Can you also measure at the output of the HD3SS3212?

Thanks

David

Hi,

Thanks for your support.

I did not add 0 Ohm resistors, but directly solder the pads together, essentially the same.

I probed on C151, C152, C153 and C154, which are the outputs of HD3SS3212 for the TX lane (TX1B P/N and TX2B P/N in the schematics shown in previous posts)

Attached two pictures. The first, shows what both TX1B and TX2B show when the system is idle. It is also the case for when the system is booted, and there is no USB device connected.

If there is USB device connected, the first picture corresponds to the lane in idle state. The second picture corresponds to the lane being used by the USB device. It seems to match what I scoped at C117 and C122.

Timoteo

When system is idle, is the hub connected to a USB SuperSpeed host? If not, you should not see this 50Hz periodical signal on the SuperSpeed line.

Thanks

David

Hi,

Yes, when I said idle, I meant with Linux booted. The USB hub is connected to a USB3 Controller from an ARM-based device. The other screenshot is for when, in the same state, a USB stick is plugged into the connector.

I also observed VBUS. It was 0. It seems there is a peak when the USB stick is connected, but in steady state, VBUS is 0V. I cut the trace of VBUS from the controller, and provided VBUS from TPS2561DRCR. This signal DN1_VBUS was unused in the previous tests I provided.

I can see 5V present at VBUS on the connector after doing this. Still, same results, same behaviour. The device is not recognised.

Best regards,

Timoteo

Timoteo

The first issue is that the USB Type-C standard requires that a DFP not enable VBUS until it is in the Attached.SRC state. So you need to understand why TPS25810 is not enabling the VBUS output if there is a valid CC1/2 connection.

The second issue is that if the TUSB8041 is properly being recognized by the Linux as a valid USB3.1 Gen 1 hub, then the hub downstream should be in RX.DETECT state. But the scope picture shown earlier is not RX Detect. Would you please check to see if the hub is properly being recognized?

Since the Type-A connector is working properly, you can also probe Type-A signal as a reference to debug Type-C port.

On the hub, I would not recommend the pullups on the PWRCTLx/BATENx lines since they enable battery charging – but this only impacts the USB 2.0 lines, not USB 3.0.

Thanks

David

Hi,

Thank you very much for your support.

Answering your previous question, yes, the USB hub is correctly recognised.

[    5.388495] usb 2-1: New USB device found, idVendor=0451, idProduct=8140     
[    5.395110] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    5.417862] hub 2-1:1.0: USB hub found                                       
[    5.421570] hub 2-1:1.0: 4 ports detected    

I put probes on the TX diff pair for the Type-A USB port.

The graphs shown below, show the activity on the TX lane in "idle" state (after booting Linux, not having anything connected to the port), and the second picture when the USB stick is connected, and recognised.

Best regards,

Timoteo

Timoteo

Do you have any tool that can be used to read the data rate being connected at the hub upstream port, whether it is USB2.0 or USB3.0? The only tool I am aware of that allows you to view USB descriptors in Linux is lsusb. The scope capture does not look like USB3.0.

Thanks

David 

Hi,

Yes, lsusb is what I was using. Here what I can read, before connecting the USB stick to the Type-A, and after connecting, both lsusb and lsusb -t:. It recognises the Transcend USB stick, being 5Gbps (USB3)

Regards,

Timoteo

Timoteo

For this Type C port, are you able to hold off from turning on VBUS until the CC connection has been completed?

If you can disconnect OEn and SEL of HD3SS3212 and force both low, can you try both orientation of the Type-C?

Thanks

David 

Timoteo

Do you have an update to this thread?

Thanks

David

Hi,

I pulled down OEn and SEL through R122 and 119, cutting the traces, but from U105 point of view, not U104. This means that I tested having OEn and SEL at HD3SS3212 floating, and pulled down for TPS25810RVCT.

No changes, same behaviour.

I will pull them down for HD3SS3212 appropriately next week.

Best regards,

Timoteo

any update?

Hi,

Sorry for the delay.

I've removed R122 and R119, and connected OEn and SEL directly to ground.

When I connect the USB stick, and do lsusb -t, I do not see anything in one of the orientations, but it reacts in this way in the other orientation:

ubuntu@arm:~$ [   65.507494] usb 2-1.1: device not accepting address 7, error -1
[   66.011495] usb 2-1.1: device not accepting address 8, error -71             
[   66.759495] usb 2-1.1: device not accepting address 9, error -71             
[   67.111721] usb 2-1.1: device descriptor read/8, error -71                   
[   67.243722] usb 2-1.1: device descriptor read/8, error -71                   
[   67.355571] usb 2-1-port1: unable to enumerate USB device   

Interesting. At least it shows some life afterall!

Timoteo

This is expected with SEL pin being tied to GND. I would expect the other orientation would work when SEL pin being tied high.

Once you confirmed that the other orientation is working with SEL pin being tied high, then the issue is not a hub or the HD3SS3212 issue, we will then have to look at the configuration of the TPS25810.

Thanks

David