Device fails to enumerate when plugged in for the first time on Windows

[VioletEternity]

Device fails to enumerate when plugged in for the first time on Windows

[VioletEternity]

• Did this happen the first ever time, and then never again after re-plugging?

Correct.

• Does a reboot get it to occur again?

It works fine after a reboot.

(does anything / can you reproduce it?)

You can artificially make it happen the second time by uninstalling the driver using the Device Manager, unplugging the device, and plugging it back in.

Also, I am fairly certain it will happen once per physical device (i.e. VID/PID/DID/serial number combination).

[VioletEternity]

No, not physical port. It was originally plugged into Port_#0004.Hub_#0002. After plugging it in Port_#0002.Hub_#0002 it works fine.

The device instance path remains the same, USB\VID_20B7&PID_9DB1\C3-20230729T201611Z, so the same device settings are used. It is only the location that is updated when it is plugged in a different port.

[VioletEternity]

In addition, it looks like this implementation of STALL_EP0() is incorrect:
https://github.com/whitequark/libfx2/blob/82d154153f548b29b1be60f1c11d7a5bc102486d/firmware/library/include/fx2usb.h#L76-L77

It should be EP0CS = _HSNAK|_STALL instead:

[VioletEternity]

This isn't correct. In case of an IN request, it is necessary to wait for EP0CS & _BUSY to clear first.

My apologies; I wasn't paying enough attention and got confused.

There is no point in waiting for EP0CS & _BUSY to clear in the beginning of the SUDAV deferred interrupt handler because it will never be set at that point:

It only makes sense to wait for EP0CS & _BUSY to clear after an EP0 data transfer has been set up. In case of libfx2, this would be after a call to SETUP_EP0_BUF, SETUP_EP0_IN_DATA, or SETUP_EP0_IN_DESC.

The issue is caused by not stalling EP0 as described here:

[attie]

Unplugging the device and plugging it back in resolves the issue.

Could you clarify?

• Did this happen the first ever time, and then never again after re-plugging?
• Does a reboot get it to occur again? (does anything / can you reproduce it?)

[attie]

Also, I am fairly certain it will happen once per physical device (i.e. VID/PID/DID/serial number combination).

Knowing Windows, possibly physical port too...! (could you confirm?)

[whitequark]

I will be able to capture ETW traces later.

I would really appreciate ETW traces (or any additional information about this issue) because I'm at a loss of where to even begin debugging it.

[whitequark]

@esden Have you already programmed all of the Early Bird units? This could be an unpleasant thing for people who use Windows to hit on their first plug in...

@attie I think we need to catch usb1.USBErrorNotSupported on Windows and ask the operator to unplug it and plug it back again to see if that solves it, until we can fix this properly >_>

[attie]

No, not physical port

That's good... FTDI UARTs (and I'm sure something else) used to have a habit of tying the COMn to a physical port.

catch usb1.USBErrorNotSupported on Windows and ask the operator to unplug it and plug it back again

I've got access to Windows too, though my knowledge is far below where it could be.
I'm a little surprised it doesn't "figure things out" and that a replug is required... but that's a good idea.

[whitequark]

I'm a little surprised it doesn't "figure things out" and that a replug is required... but that's a good idea.

It might be related to WinUSB somehow?

[whitequark]

@VioletEternity Could you test #385, please?

[VioletEternity]

I've attached the ETW trace capturing USB transactions on first plug-in of the device:
usbtrace.zip

It seems that the cause of the issue might be the failure of the requests with FNs 378 and 390:

I've included the requests below:

[VioletEternity]

It looks like an unrecognized USB request that is received by the device will always fall through to this line:

glasgow/firmware/main.c

Line 837 in 3146305

STALL_EP0();

This isn't correct. In case of an IN request, it is necessary to wait for EP0CS & _BUSY to clear first.

As a result, EP0 is stalled after an unrecognized Microsoft-specific request arrives, but instead of rejecting just this request, a following GET_DESCRIPTOR request is also rejected. This causes the Windows USB stack to mark the device as faulty, since a GET_DESCRIPTOR(Device) should always succeed. Windows only queries the Microsoft OS descriptor on the first plug-in, so on the next one the issue does not arise.

[whitequark]

All right, I can't quite get it to work right now, but I also realized that I think I understood this part of the FX2 TRM wrong this whole time and I need to rewrite a significant amount of code. I'll do this tomorrow >_>