Enumeration problem with mac M4

[spacemic]

Here is a problem: When connecting my usb device directly to a mac with the M4 chipset, it enumerates and registers just fine. However, when connecting it through the USB sniffer, it does not. Here is the log:

11074 3.269570050 host 0.0 USBLL 3 SETUP
11075 3.269570383 host 0.0.0 USB 11 SET ADDRESS Request
11076 3.269570833 0.0 host USBLL 1 ACK
11077 3.269571800 host 0.0 USBLL 3 IN
11078 3.269572133 0.0 host USBLL 3 DATA1
11079 3.269572566 host 0.0 USBLL 1 ACK
11106 3.272725700 host 1.0 USBLL 3 SETUP
11107 3.272726033 host 0.1.0 USB 11 GET DESCRIPTOR Request DEVICE
11108 3.272726500 1.0 host USBLL 1 ACK
11109 3.272728316 host 1.0 USBLL 3 IN
11110 3.272728650 0.1.0 host USB 21 GET DESCRIPTOR Response DEVICE
11111 3.272731833 host 1.0 USBLL 3 IN
11112 3.272732183 1.0 host USBLL 3 DATA0
11113 3.272735233 host 1.0 USBLL 3 IN
11114 3.272735566 1.0 host USBLL 3 DATA1
11115 3.272736000 host 1.0 USBLL 1 ACK
11116 3.272737816 host 1.0 USBLL 3 OUT
11117 3.272738150 host 1.0 USBLL 3 DATA1
11118 3.272738466 1.0 host USBLL 1 ACK
19133 4.275507350 Syslog 31 --- Bus Reset ---

The problem does not occur when using an earlier chipset (M2) or when connecting through a hub. Any ideas what is going on here? For reference, here is a log from a successful connection to the same host, but with a hub is inserted between the sniffer and the host:

438 4.345791850 host 0.0 USBLL 3 SETUP
439 4.345792183 host 0.0.0 USB 11 SET ADDRESS Request
440 4.345792650 0.0 host USBLL 1 ACK
441 4.345793850 host 0.0 USBLL 3 IN
442 4.345794200 0.0 host USBLL 3 DATA1
443 4.345794866 host 0.0 USBLL 1 ACK
447 4.346211383 host 3.0 USBLL 3 SETUP
448 4.346211716 host 0.3.0 USBHUB 11 GET_STATUS Request [Port 2]
449 4.346214133 host 3.0 USBLL 3 IN
450 4.346215116 USBLL 1 ACK
451 4.346216533 host 3.0 USBLL 3 OUT
452 4.346216866 host 3.0 USBLL 3 DATA1
475 4.348868050 host 8.0 USBLL 3 SETUP
476 4.348868383 host 0.8.0 USB 11 GET DESCRIPTOR Request DEVICE
477 4.348868833 8.0 host USBLL 1 ACK
478 4.348870866 host 8.0 USBLL 3 IN
479 4.348871200 0.8.0 host USB 21 GET DESCRIPTOR Response DEVICE
480 4.348872166 host 8.0 USBLL 1 ACK
481 4.348873450 host 8.0 USBLL 3 OUT
482 4.348873783 host 8.0 USBLL 3 DATA1
483 4.348874116 8.0 host USBLL 1 ACK

To summarize:

Chipset	Hub	Sniffer	Works
M2	no	no	yes
M2	no	yes	yes
M2	yes	no	yes
M2	yes	yes	yes
M4	no	no	yes
M4	no	yes	no
M4	yes	no	yes
M4	yes	yes	yes

[ataradov]

It might help to have *.pcapng files for both cases. Does it happen consistently this way every time?

Given the table, it looks like there some signal degradation added by the sniffer and there may be some difference in routing in M4 that it matters. Hubs redrive the signal, so it helps to have the hub in a path.

There are a couple things I would try:

1. Different cables in the sniffer path. Preferably shorter and USB3 capable. USB3 part will not be used, but USB3 cables have generally better wires.
2. Different target devices, including some FS.

[spacemic]

It is consistent, yes. I will try some different cables. Other devices work fine with the same computer. The reason I'm trying this is that the same device is having other problems with this and other M4-based computers. Without the sniffer, enumeration works, but it drops connection later. Using a hub solves it. So my guess is that the signal integrity is on the limit of what the M4 tolerates. All other hosts I've tested are okay with it though. The device uses a USB3318 chip.

pcap.zip

[ataradov]

Something strange going on with this device. The part you need to pay attention to here are the 50 us J-K line state changes. They are a part of the HS enumeration process. "single" and "both" denotes how many devices have enabled HS termination. The process starts with HS capable host enabling HS termination and toggling the line. Device detects that and enabled its own termination ("both"). This is when the bus transitions into HS state. You can see in the good log that it went to both after about 10 transitions. This is exactly what supposed to happen.

In the bad log you can see that it never went to "both". But some of the frames are captured in HS mode, which means that host must have detected them and detection thresholds in the sniffer did not see that. Sniffer thresholds are set at very safe levels, so it looks like the device is marginal. It might have damaged transceiver or something like this.

There are a few more things you can try:

1. Capture logs and observe the behavior when the sniffer is placed between the hub and a PC, and when the sniffer is placed between the hub and the device.
2. Use a scope and try to capture those 50 us transitions at the beginning of the enumeration. Don't worry that the scope may introduce more load (it will), you are interested in just the voltage levels during that 50 us JK toggle period.
   You want to observe the voltage drop after 10 toggles that sniffer can't see. The voltage level at this point will tell you what is going on.

[spacemic]

Here is a scope of the device connecting to an M2 mac. The probes are x10, so the voltages seem to be right. I don't have an M4 mac here, but I'll try that later.

[ataradov]

It is very hard to read the level accurately. Increase vertical scaling as much as you can. The minor differences matter.

If I'm interpreting this correctly, then it looks like single device level during JK chirp is 800-900 mV, which is within the required range (700 - 1100 mV).

Both device level is maybe around 400 mV, which is also in the expected range of 360 - 440 mV.

But this is the case that works. It would be interesting to see what happens on the setup that does not work. And in better vertical resolution, of course.

[spacemic]

Here's the chirp with the M4-based mac. Same settings and same device as before. It seems very much not in spec.

[ataradov]

Yes, this looks different. But this would be a host issue. Do all USB ports behave like this? Is there a way to try with multiple PCs? It may be just a damaged port.