TUSB8043A: Schematic Review

Hello Lumina,

Can you share the conditions where the resets occur?  Does it happen with USB 3.0 devices or USB 2.0 devices or both?  Do the device enumerate but then reset occur during device operation?  In general, with the TUSB80xx the most frequent cause of issues is insufficient ground pad connection.  Can you confirm the thermal pad is well connected to the PCB?  Please note that the HD3SS3212 switch requires a bias voltage if AC caps are used on both sides.

Schematic review feedback:

USB_VBUS is a detection input and should only be high when an active host is connected.

Functionally, the design looks ok but if the hub must past USB-IF compliance testing the following items would be needed:

• OVERCURRENT reporting would have to be added to the application.
• Any unused or permanently connected ports would have to be marked via i2C or SMBUS.
• FULLPWRMGTz should be set high

A 1uF capacitor on GRSTz is fine for most applications, but if the power supply ramp time is long, they may need to increase it to 2 uF to meet the power on reset
timing conditions.

Regards,

JMMN

Hi JMMN,

The reset problem just occurs on USB3.0, when the system communicate with the USB storage device repeatedly read/write data. The problem could be reproduce by the following script:

However, it has been found that this problem can easily recur on ELECOM USB disks, but other USB disks may recur when pushing stream files are saved for a long time. 

Through the software investigation, the reasons for locating the USB disk reset are as follows:

The USB received an error: -71: Protocol error while transmitting data, causing the kernel to reset the device through software. And the reason of  -71 ERROR appears is that there is a Completion Code: 4 reported in the xHCI interrupt.

According to TRB Completion Codes from Intel's eXtensible Host Controller Interface for Universal Serial Bus section 6.4.5, the USB host did not receive a valid response from the device. 

Regarding for the schematic review feedback, we have the following reply:

1) USB_VBUS is set to pull high as soon as the system is turned on, there is no problem.

2) We have no requirement to pass the USB-IF certification, and the three points mentioned in your previous reply will not result to the reset problem.

3) Currently TUSB8043A has no problem with power on, so 1uF capacitor on GRSTz should be enough.

Thanks,

Best Regards

Lumina

Hi Lumina,

This looks like a signal quality issue, do you see the behavior change with different cables / cable lengths?  Can you share the layout from the hub to the downstream port?

Regards,

JMMN

Hi JMMN,

Our customer have done some testing for the USB HUB, the result was shown in the following document.

USB transmission interruption issue.pptx

We use two ports of the HUB to connect two Type-A connectors. When inserting just one USB3.0 disk for data transmission with the system, the transmission will be interrupted due to unknown reasons after a period of time. However, this problem did not occur when inserting two USB3.0 disks at the same time and using one of them for data transmission.

By the way, our customer also have conducted a test to remove the USB HUB by connecting TX/RX/D+/ D-pad to the jumper.  Currently, we are still running for 87 hours without any problems, which seems to be the problem of HUB.

Our customer is also wondering if TI can provide the firmware for the pattern of USB3.0 HUB testing.

Thanks,

Kind Regards

Hi Lumina,

The TUSB80xx hubs do not have any firmware for testing.  Since using two downstream USB 3.0 devices simultaneously works, this is likely an issue with how the U1/U2 power states are being used not signal quality.  Can your customer try disabling USB 3.0 U1/U2 entry to confirm if that fixes the issue?

Regards,

JMMN

Hi JMMN,

Our customer has tried to disable the USB3.0 U1/U2 before, but the problem still exists. Is there any other suggestion for this problem? 

Thanks,

Best Regards

Hi Lumina,

Can the customer provide any information about the data during the failure like a protocol trace or USBMON debug output?

Regards,

JMMN

Hi JMMN,

The following is the main kernel log and usbmon log when usb reset occurs, I hope it will be useful to you.

kernel log:

[ 118.409241] Command READ_10 (10 bytes)
[ 118.409245] bytes: 28 00 00 00 3a 0c 00 00 01 00
[ 118.409251] Bulk Command S 0x43425355 T 0x809 L 512 F 128 Trg 0 LUN 0 CL 10
[ 118.409254] xfer 31 bytes
[ 118.409281] usb_hcd_map_urb_for_dma: dir: DMA_TO_DEVICE
[ 118.414484] xhci-hcd xhci-hcd.1.auto: USB Transaction Error
[ 118.414490] xhci-hcd xhci-hcd.1.auto: Transfer error for slot 4 ep 3 on endpoint
[ 118.414505] xhci-hcd xhci-hcd.1.auto: Cleaning up stalled endpoint ring
[ 118.414509] xhci-hcd xhci-hcd.1.auto: Finding endpoint context
[ 118.414513] xhci-hcd xhci-hcd.1.auto: Cycle state = 0x0
[ 118.414517] xhci-hcd xhci-hcd.1.auto: New dequeue segment = pK-error (virtual)
[ 118.414521] xhci-hcd xhci-hcd.1.auto: New dequeue pointer = 0xf3e2bf80 (DMA)
[ 118.414524] xhci-hcd xhci-hcd.1.auto: Queueing new dequeue state
[ 118.414529] xhci-hcd xhci-hcd.1.auto: Set TR Deq Ptr cmd, new deq seg = pK-error (0xf3e2b000 dma), new deq ptr = pK-error (0xf3e2bf80 dma), new cycle = 0
[ 118.414532] xhci-hcd xhci-hcd.1.auto: // Ding dong!
[ 118.414539] xhci-hcd xhci-hcd.1.auto: Giveback URB 0000000028622a5e, len = 0, expected = 31, status = -71
[ 118.414600] xhci-hcd xhci-hcd.1.auto: Ignoring reset ep completion code of 1

[  118.414642] Status code -71; transferred 0/31

[ 118.414647] Bulk command transfer result=4
[ 118.414650] -- transport indicates error, resetting

usbmon:

ffffffe72bc48a00 118380415 S Bi:4:003:1 -115 13 <
ffffffe72bc48a00 118380450 C Bi:4:003:1 0 13 = 55534253 08080000 00000000 00
ffffffe72bc48a00 118409249 S Bo:4:003:2 -115 31 = 55534243 09080000 00020000 80000a28 0000003a 0c000001 00000000 000000
ffffffe72bc48a00 118414534 C Bo:4:003:2 -71 0
ffffffe7171d7c00 118414707 S Co:4:002:0 s 23 03 0017 0001 0000 0
ffffffe7171d7c00 118414817 C Co:4:002:0 -71 0
ffffffe7244c6700 118414931 S Co:4:003:0 s 00 30 0000 0000 0006 6 = 0e0bf80f f50f
ffffffe7244c6700 118415077 C Co:4:003:0 -71 0
ffffffe7244c6700 118415115 S Co:4:003:0 s 00 30 0000 0000 0006 6 = 0e0bf80f f50f
ffffffe7244c6700 118415212 C Co:4:003:0 -71 0
ffffffe7244c6700 118415262 S Co:4:002:0 s 23 03 0005 0301 0000 0
ffffffe7244c6700 118415353 C Co:4:002:0 -71 0
ffffffe7244c6700 118415509 S Ci:4:002:0 s a3 00 0000 0001 0004 4 <
ffffffe7244c6700 118415605 C Ci:4:002:0 -71 0
ffffffe72dff5000 118427545 C Ii:4:001:1 0:2048 1 = 02
ffffffe72dff5000 118427615 S Ii:4:001:1 -115:2048 4 <

Hello Xiaobo,

Can you provide more of the kernel log / usbmon?  I need to see the section before the error as well. You can attach a file if needed.

Regards,

JMMN

Hi JMMN, 

I uploaded usbmon2.zip, which contains dmesg log (dmesg.log), complete kernel log (kern.log) and usbmon log (4u.log)

usbmon2.zip

Thanks,

Best Regards

Thank you for providing, I will need a day to review.

Regards,

JMMN

Hi, JMMN

Can you get useful information from kernel logs and usbmon logs?

We used the lecroy analyzer to record the error data, and Qualcomm analyzed it as follows:

As per the lecroy logs, multiple Undefined Symbol  Sequence errors detected, which in your case is caused by bad signal integrity

Suggest to tune hub usb signal integrity according to eye diagram report

Do you have any suggestions for errors indicated by the analyzer? How do we tune the hub signal integrity?

Thanks,

Best Regards

Hi Xiaobo,

Can you provide more of the LeCroy trace?  Or the full LeCroy trace?  That is the best tool to debug USB issues.

Regards,

JMMN

Hi, JMMI

The trace file upload always fails, even if I split the file into multiple small files.

Is there any other way to give you the trace file (113M)?

Thanks,

Best Regards

Hello Xiaobo,

I have sent you a friend request so we can discuss offline.  You can either share the file for download from Google drive or Box account or similar.  If you do not have access to a file sharing service, send me your email over direct message and I will try to set up something.

Regards,

JMMN

Hi, JMMN

I uploaded two full lecroy trace files to google drive:

I have sent you the google drive link of the full lecroy trace file,

please help to analyze.

Thanks,

Best Regards

What is the difference between the files?

In one case, the link enters U1 correctly but instead of exiting back to U0, the host sends a warm reset.  The hub would not generate a warm reset on a port unless the host sent it, I am not sure why this occurs? 

In the other case, the link enters U1 for 3+ seconds and then the link is disconnected.  It is difficult to determine what is happening without see the host to hub traffic, but the signal quality looks good (the USS packets are just artifacts of the Lecroy tool).

I am very surprised that disabling U1/U2 didn't fix this issue, can you provide a trace with U1/U2 disabled?  Right now it looks like the host driver does not handle U1/U2 with hubs properly.

Regards,

JMMN

Hi, JMMN

There is no difference between these two cases. They are two sets of identical tests. The only difference is that the ports used are different. Two TypeA are connected downstream of the hub, so there are two tests. What we observe is the same.

From the software log, when transferring files, the kernel received an error code -71 (protocol error), and then reset the device. The warn reset in case 1 may be that the kernel has received a protocol error and then actively reset the device.
So, I suspect that the error you pointed out may not be the first error, there may be more errors ahead, can you confirm it again?

Our host controller has u1/u2 disabled by default, but I just noticed that the hub can also disable u1/u2 by configuring the hub's registers. Can the hub still enter u1/u2 when the host controller has disabled u1/u2? I don't know how to modify the registers of the hub, can you give me some advice, how to disable the u1/u2 of the hub?

Thanks,

Best Regards

Hello Xiaobo,

Yes, the end result would be the same from both traces but the protocol looks a bit different, the trace that shows the warm reset doesn't show any errors before that just an entry to U1.  U1/U2 is definitely still enabled in this system.  The hub cannot initiate a U1/U2 entry unless the feature is enabled by the host and these protocol traces show that both U1 and U2 are enabled and in frequent use:

If the customer cannot disable U1/U2 on the host, they can do it by setting register 05h in the hub.  This would require an EEPROM or I2C/SMBUS host be connected to the hub.  I would recommend just using a I2C host to set the bit for a test to verify that this fixes the issue.

Regards,

JMMN