- Please upgrade the driver to CYUSB3 driver version 184.108.40.206.
- Also, mention the host controller model on which the issue is seen.
Upgrading the driver was one of the first things we tried. We observed the problem on the XPS 15, with an i7-8750H, which appears to use the ASMedia USB Extended Host Controller Driver.
We ended up just adding a dummy isochronous endpoint, requesting 1kB of bandwidth every other micro-frame. This seemed to do the trick, preventing the host from dropping into whatever power-saving mode it was doing. It's a cheesy solution so we're still open to other suggestions.
Comments imply Cypress driver+API?
For reference we have a system that streams data from 4x5MP cameras via an FPGA/FX3 to Windows hosts. That's currently ~200MB/s. Uses the MSFT bulk driver and WinUSB. Extremely reliable.
It might be worth a look, as relevant code can be mashed up pretty quickly. Look out for the 'Zadig' tooling to handle driver installation for the device VID+PID.
Good luck and do post if you try this.
I'd be curious if you've tried this on an 8th generation i7 running Windows 10. We never had a problem before 8th gen processors on Windows 10. We have thousands of systems deployed using ~200 MB/s bulk transfers, and now 2 customers in one week reporting a problem we can readily duplicate. But as more customers get these 8th gen processors and Windows 10, I am concerned it could quickly become a major problem.
Indeed. 8th gen: sadly not to hand. Latest round of test kit is 7th.
Sorry not to be of more help.
"Comments imply Cypress driver+API?"
Ah, tricky question. We actually tested both ways, but different hardware platforms. Our new product has a similar problem, and I did upgrade to the latest SDK and rebuild (we were at 1.3.3). It made no difference. Our older product I still maintain on an older version of the Cypress tools (probably change a couple of lines of code about once a year). I didn't bother upgrading when the latest SDK had no effect on our new product.
They both responded favorably to adding the dummy isochronous endpoint, which seemed like a slightly better solution than adding a couple of threads with busy loops (our customer's workaround while we found a better solution), and both survived a 16 hour gap-free streaming test.
- Can you please upload the USB traces captured on the bus using a protocol analyzer such as TotalPhase or LeCroy?
- Also, if possible, try to disable the low power settings in the BIOS and check if the issue still persists. With latest generation processors, more deep sleep states are introduced, which drive the core into low power states irrespective of USB transfers.
- As an alternate idea, you can implement a dummy thread in your application to keep the CPU busy and prevent it from entering the low power states.
Please test and let me know the results.