I can report back that the issue is sometimes likely that the BSP masks the disconnect interrupt when handling the connection interrupt. Because of this, you can land in an endless loop in the host processing state machine where you leave off in the HOST_DEV_WAIT_FOR_ATTACHMENT state, and then on reconnect immediately enter the enumeration state without having sent a reset command to the USB device, thereby getting no response. With no response I inserted a timeout that would reset the state machine, however, I did not know that I also needed to indicate that there was a disconnect before resetting the state machine. I thought that this would be handled by shutting off power to the USB, but I think that this combination of events leads to a mask of the disconnect interrupt. Therefore, the state machine would run right back into the waiting for attachment state in an endless loop. Simply calling the disconnect ISR callback in between re-connection attempts solves this issue.
That is the first issue I solved, the following two are less nuanced.
Some USB sticks required a long initial wait period before starting to send communication to them. These devices fall far outside of the USB specification when it comes to enumeration timing, or at least they do when connected to my host device. I ended up having to wait almost a full second before starting the enumeration sequence. After waiting a full second these devices work with no issue.
Specific USB 3.0 sticks tend to not work with my device at all and it does not seem resolve-able through software. I will sometimes receive the device descriptor back when I request it, and then later on the control request endpoint zero will stall. Other times I don't even get the device descriptor. It seems like a random breakdown of communication that likely happens because of noise. If anyone has working 3.0, please let me know if it was a struggle and how you handle noise/repeated stalls.
