Invalid PID Sequence

[wocard2]

Capturing low-speed USB works just fine, but for a high-speed device, I see only packets sent from the host to the device (no packets sent from the device to the host) and some ACK packets that look like this:

Frame 240: 1 byte on wire (8 bits), 1 byte captured (8 bits) on interface usb, id 0
Section number: 1
Interface id: 0 (usb)
Encapsulation type: High-Speed USB 2.0 packets (217)
Arrival Time: Jan 1, 1970 01:00:10.484624116 CET
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 10.484624116 seconds
[Time delta from previous captured frame: 0.000009416 seconds]
[Time delta from previous displayed frame: 0.000009416 seconds]
[Time since reference or first frame: 10.484624116 seconds]
Frame Number: 240
Frame Length: 1 byte (8 bits)
Capture Length: 1 byte (8 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usbll]
USB Link Layer
PID: ACK (0xd2)
[Expert Info (Error/Malformed): Invalid PID Sequence]
[Invalid PID Sequence]
[Severity level: Error]
[Group: Malformed]

Haven't tried a full-speed device yet.

What could be wrong with my build of your USB sniffer?

[ataradov]

What OS you are using? Did you set the correct speed in the settings?

Normally there is no difference for the sniffer which side sends the data. So, I'm inclined to think that there may be a signal integrity issue due to bad cables or connectors. Does the device under test work as expected when connected though the sniffer?

[wocard2]

The OS is Linux. I set the speed to high speed. The DUT (a flash drive) does work when connected through the sniffer.

[ataradov]

Capture a small, but complete log from plugging in the drive.
If only one side is visible, it must be some sort of signal integrity issue. I would definitely try with different cables.
Another possible option is incorrect clock for the USB PHY, but it must be just a bit off for anything to be received at all.

[wocard2]

I see the chirp, then SOF, IN, and the ACK packet shown above (with "Invalid PID sequence"), followed by more IN, SOF, and ACK packets of the same type.

[ataradov]

I would try with different devices to collect some statistics on what works and what does not. It may be specific to that device.

[wocard2]

hs-storage-bad2.pcapng.gz
I already tried different cables.

[ataradov]

I would say this is some sort of a clock issue. Only very short packets are received. Host would also send a lot of SETUP packets, and you can't see a lot of those.

What clock generator IC did you use? Also, what speed grade FPGA? I would check the frequency and stability of that clock and of the resulting 60 MHz output clock.

[wocard2]

Maybe a problem with the capacitors? As 1 µF capacitors that don't lose a lot of capacitance at 5 V in 0603 packages are hard to find, I used 50 V 0805 capacitors for the LDO, but I left all the other capacitors at 0603. For the 2.2 µF 0603 caps I had only 16 V specimen in stock, maybe I should replace these.

https://pdfserv.maximintegrated.com/en/an/[TUT5527.pdf](https://pdfserv.maximintegrated.com/en/an/TUT5527.pdf

[wocard2]

Speed grade 5 for the FPGA, the 26 MHz oscillator is a Yangxing Tech OT2EL4C4JI-111OLP-26M (sorry about that) with ±10 PPM. Haven't measured the 60 MHz clock yet, only checked if it's present. Apart from my 200 MHz scope I only have a 10 MHz frequency counter (with TCXO), I'd need a divider for that.

[ataradov]

I doubt it. I did not do anything special for the capacitors, just used nominal values. There are a lot more capacitors than actually necessary on that board, partially to account for potential DC loss.

This is either clocking issue, or PHY damage. PHY may have damage in the HS RX path only, for example.

I would just try with a lot more devices, including FS and see if there are any patterns show up.

[wocard2]

The LDO has only the minimum values for the caps nearby and some 0603 50(!) V caps from reputable manufacturers lose 40% of their capacitance at 5 V.

[ataradov]

Is 3.3 V power rail stable? If so, then capacitance it enough. You are really looking at it from the wrong end.

I've used that series of oscillators for 12 MHz and they worked fine, I have no reason to suspect they are bad.

Do more experiments with different devices.

[wocard2]

The T_USB_CLK frequency is 60.0006 MHz according to my scope. No jitter visible.

[ataradov]

Try with different devices, including FS.

I would suspect some PHY damage. No idea why it might happen.

Replace the PHY and see if that helps.

[wocard2]

Perhaps the USB3343 got too hot during soldering.

[wocard2]

I tried a different storage device: this time I see SCSI packets!

[wocard2]

However, there still are ACK packages with "Invalid PID Sequence".

[wocard2]

While capturing, the 3.3 V rail has 3.3007 V (multimeter) with 12 mV peak-to-peak noise (scope), measured across the EEPROM, that was the only place I found where I can conveniently use a scope probe without resorting to using that ground wire aka antenna.

[ataradov]

What is your hardware setup? It looks like there is a hub somewhere because even in your initial log I see hub commands to reset the ports.

Ideally you want to use the root hub interface with no additional hubs, since that degrades performance quite a bit. But I'm still not sure why packets would go missing like this. Even if there is an overflow, there must be a message about that. Strange.

[wocard2]

hs-storage-good2.pcapng.gz
Here's flash drive A mounted and unmounted. Any packets missing?

[wocard2]

Speed test 1: USB 2.0 at root hub
Speed test 2: USB 3.0 probably with some internal hub
Speed test 3: USB 3.0 probably at root hub

[wocard2]

With USB, there are always hub commands as there's always a hub.

[wocard2]

Here are screenshots from usbview for the three speed tests. Interestingly, the fastest test has one hub more than the second-to-fastest test.

[ataradov]

This is exactly how it should look like (the log I mean).

There are not always hub commands, even the sample HS log in that repo does not have them. This was captured from my PC with a sniffer attached to the root hub. Root hub does not have ports, so requests to reset a port are meaningless.
This is some implementation detail of that host controller.

[wocard2]

(These are three images, "MyUSB Drive" is where the USB sniffer was connected for the respective speed test.)

[wocard2]

So, avoiding hubs isn't always the solution (see speed test 3 vs. speed test 2).

[ataradov]

What PC / motherboard is this? There is something in its architecture that does not make sense.

Using the fastest port is always a good idea, that's why there is a speed test command. But I don't have any explanation for the observed results.

This may be also some OS/drivers issue. Or those host controllers connected in different ways resulting in different performance.

[wocard2]

Interestingly, usbview claims that that fastest xHCI controller (test 3) runs at 480 Mb/s and the "middle" xHCI controller (test 2) runs at 5 Gb/s. I think usbview confused those two xHCI controllers. That way, the results make much more sense.

The motherboard is quite old, it uses the Z77 chipset. But I have some additional USB 3.0 host adapters installed, the USB port that turned out to be fastest may be connected to one of these.

[wocard2]

BTW, I'm using an MCP1755T-3302E/O instead of a MIC5504-3.3v. It's more expensive, but I already had some of them. Shouldn't make a difference and the measured 3.3 V rail looks good.

[wocard2]

Ah, I misread the indentation in the third image (fastest): "MyUSB Drive" (and therefore the USB sniffer for speed test 3) is connected directly to the root hub, not to the hub! I have too many hubs...

[ataradov]

Voltage regulator should not matter. I just used the one I had in stock.

I guess I'm missing something with the way those hub commands are sent. It does not really hurt anything, I was just not expecting to see them in the log.

[marcosribeirobr]

@wocard2 I'm curious to understand if the problem was solved?

[wocard2]

Yes, when connecting the sniffer to my fastest USB port (that xHCI controller is probably provided by the Intel C216 chipset) without hub, high-speed sniffing works just fine.