Issue with high speed devices

[bkerler]

Hi,

I've built two boards and both works fine with low-speed and full-speed devices. However if I try to connect any high-speed device such as a android smartphone, the device cannot be enumerated (neither adb, fastboot nor serial). I checked the oscillators and they deliver 24 mhz and 26 mhz as expected, 60 mhz at the usb_clk of the usb3343. Voltage measured at vdd18 is 1.78V. Doesn't matter if the capture is on or not, the usb enumeration fails all the time and the device isn't detected.

Any ideas why the usb enumeration fails ?

usblog.zip

[ataradov]

Try different USB port on the PC and don't use hubs for the target device. Also make sure that the board are clean from flux contamination. Some fluxes are mildly conductive and may cause issues at high frequencies.

The logs looks similar to another issue and there the problem was resolved by using a different USB port.

Also, just for statistics, what PC/motherboard you are using?

[bkerler]

Ok, it seems I've figured out what the issue is on high speed.

SW-Side:

1. Capture has to be started at least once host port usb-c was connected, otherwise it fails
2. Always connect the device port first (USB-A), then the sniffer port (USB-C), otherwise it fails.

HW-Side:
On the host port (host -> sniffer, usb-c) anything (usb 2.0/usb 3.0/usb 3.1) except usb 4.0 hub works.
On the sniffer port (usb-c nearby usb-a port) only usb 2.0 hub works (here: Realtek Semiconductor Corp. RTS5411 Hub)

I've tested it on two amd systems (usb 3.1 regular pc and usb 4.0 laptop lenovo z16).

So I'm still wondering if the usb3343 doesn't like amd hubs or if it's an issue with the two boards that I've got (both were fully pnp by jlcpcb except the usb3343). On the optical side using microscope I couldn't see any potential issue.

[bkerler]

Could it be that the cc1 and cc2 lines might cause issues ?

[ataradov]

Capture running or not is a purely logical thing, it does not affect the transceiver state, so it should not matter.
Order of device connection also should not matter. Something is just marginal in that setup.

It is better to avoid hubs for performance reasons, especially for the sniffer itself. Hubs decrease available bandwidth quite a bit. What does speed test say, BTW?

A sniffer has to break the signal lines in order to tap into them, so there will be some loss of integrity, plus transceiver and comparators add extra load. Even if not significant, it is not zero, which may push marginal configurations into unstable mode.

It is strange to me that in your logs transceiver can't receive any frames at all, even broken ones. So, something breaks to the point where even sync sequence is damaged.

How would CCx lines cause the issue? The sniffer has required resistors on the USB-C side. In that respect electrically it is no different than any Type-C to Type-A cable.

[bkerler]

No, cc1 and cc2 can be ruled out as both usb-c are connected via the same resistors. So seems clearly the usb3343 or IC6 is causing the issues. I had to replace the IC6 with this chip : 3N26000G33YC, just to rule that out, could this one cause the issues ?

[ataradov]

Although no, there are SOF and Get Device Descriptor requests from the host. The device does not respond, so it is not the sniffer that can't see the frames. You can see the host retries many times before giving up. So, it also can't see them. It is Android phone that can't seemingly interpret them after whatever minor loss is introduced by the sniffer.

Try with different devices, including simple stuff like USB flash drives. This may be just Android phone issue and it being marginal.

+/- 30 ppm generator should be good enough.

[bkerler]

Tried with several high speed devices including usb sticks, they all seem to have the same issues on enumeration, only a specific hub setup (usb 2.0 on the device side) does work. Without the sniffer (or with beagle480 sniffer instead), everything seems to work fine, so it has to be something the sniffer introduces. I saw that the issue #7 seems to have had the same problems.

Speed test says 44.90 MB/s.

[bkerler]

Seems the issue is the usb3343, found an answer in a forum :
errata

forum_message

[ataradov]

I have no idea what it could be. I doubt it is the transceiver. If anything, it would be the comparators.

I have not done significant testing with hubs, since the plan was always to connect as close to the root hub as possible.

This errata has nothing to do with this, since PHY here is fully passive. The whole sniffing tap should not introduce significant distortion between the devices.

The most likely issue is signal integrity caused by discontinuity in the path and multiple taps going the comparators and the transceiver.

The best way to test this would be to remove the comparators and check if it still behaves the same.

[bkerler]

Ok, will try to remove the comparators then and retest the behavior.

[ataradov]

Also, RTS5411 sees to support USB3.2 Gen1, so it is not just UBS2.0 hub. And in either case, none of them should care, since we are clearly only using USB2.0 part.

[ataradov]

Another possible factor - the cables. I just tried to experiment with hubs. The only type of hubs I have is this https://www.amazon.com/gp/product/B00JX1ZS5O . I chained two of them just to add extra challenge.

I used Pixel 3a as a target to get as close to your setup as possible.

With the first test I used one good USB cable and one random Chinese (with silicone cable, so super flexible). With that setup I had all sorts of issues. Not missing packets entirely, but CRC issues and random packet drops, device failed to connect half the time.

I replaced the Chinese cable with a good one and all issues went away, it works perfectly every time though both hubs.

The "good" cables I use are https://www.amazon.com/gp/product/B01GGKYR2O/ , which perform very well.

For the flexible cables - I suspected they are not the best, but I really like how flexible they are. And with that cable and direct connection (no sniffer), the phone also works.

So, obviously sniffer adds some distortion, which is to be expected. But it only affects the result with bad USB cables. The same setup with a cable swapped works just fine.

[ataradov]

And this is something to keep in mind too - with the sniffer you have double the cable length. Even if the sniffer is ideal and does not cause additional distortion, increasing the cable length may cause issues on its own.

[wocard2]

Could adding one (or two) TUSB216 or TUSB217 to the design help with bad and/or long cables?

[ataradov]

Impossible to tell without having proper measurement equipment and understanding what any of the issues are. And I don't have such equipment.

I don't consider it to be a serious issue. Using good cables is a good idea no matter what.

[bkerler]

I did more tests and it seems that the sniffer works with android phones with microusb pretty well but has issues with smartphones with usb-c port (even though these only have usb 2 in fact). So far no difference with the comparators removed / replaced