We have seen some issue when FX3 is used with Intel USB 3.0 Host. It will be fixed in next release of the SDK.
You can get the test build of the FX3 SDK from:
Installing the MSI will require uninstall of the previous SDK (and maybe the Eclipse and ARM GCC as well if they used the full installer previously). If this is not acceptable, all of the files in the release can be obtained from the ZIP file below:
Both of these links are publicly accessible and can be used directly. Please go through the release notes (change log and known problems sections) before starting to use the new SDK.
in this SDK you can Disable LPM by CyU3PUsbLPMDisable. let me know if this helps.
I am already using this release version, you wrote. The callback is still interrupted from the host each 1ms. For WHQL certification the device has to use the U1 and U2 states, but if I disable it, then it won't use them. Is there a way to pass the command verifier test (necessary for WHQL) without going to these states?
The performance using the intel xHCI is still as good as USB2.0 high speed. If I use faster data throughput then the usb transfers are failing!
the cypress example from FX3 SDK version 1.1.1 is also not working. If I upload the BulkLoopAutoEnum example through the Intel USB3 xHCI Host controller with the cyprss control center then it hangs in a endless loop and I can not do anything furhter with the control center. If I connect through USB2.0 host controller it works.
appendix to previous post.
I am trying this with the FX3 DVK board rev. 3
I have the same problem with Intel Z77. The function CyU3PUsbLPMDisable() solve it. But for reconnect device it need use function CyU3PUsbLPMEnable() before reconnecting.
So I've got 6 boards with FX3 on and one of them had troubles renumerating after downloading firmware on my laptop with the intel USB3 eXtensible host controller (driver 18.104.22.168). I found this thread and added the LPMdisable function and the one board magically works now. So, I'm unsure why it is only on one board that I see this problem and why this fixes it, I am a bit concerned that the advice in the API guide is not to use this function indisciminantly, should I not be making this call at the beggining and then just letting the device run forever? Do I need to add a callback or something in order to re-enable at USB connect or reset events?