LPC4357 High-Speed USB Device Bulk-IN transfers I/O error on Linux

[lpcware]

Content originally posted in LPCWare by kollesok on Tue Sep 16 08:59:15 MST 2014
  Hi everyone.
  While playing around with the USB High-Speed module on LPC4357 I came across a weird behavior of the Bulk-IN transfers on a few Linux machines. I use libusb-1.0 to measure a bandwidth of the Bulk pipes - the test is simple - I send 10MB of random data back and forth and measure how much time it takes.
  At first I ran the test on MacOSX using IOKit Framework as a USB front-end, everything worked perfectly, no errors, no timeouts. Then I switched to Linux with libusb-1.0, three ancient PCs passed the test just fine, but the two new ones showed some instability - from time to time Bulk IN transfers ended up with an error -71 (-EPROTO), which, according to the kernel documentation, means a) bitstuff error  b) no response packet received within the prescribed bus turn-around time c) unknown USB error; these errors show up rarely - 1-3 times per 1000 transfers.
  Both machines have the same motherboard: ASUSTeK COMPUTER INC. H87-PLUS - Intel® H87 chipset with USB-3.0 support.  At first I thought the problem was with the 'xhci' USB Host driver, for some systems it is still buggy, but then I turned off the XHCI support in BIOS and 'ehci' driver showed the same behavior.
  Another strange thing - when I use an external USB 2.0 Hub to connect the device to these Linux systems, everything works fine with both 'xhci' and 'ehci' drivers. 

  For LPC4357 I have written a custom Device Driver based on the LPCUSBLib, but the exact same thing happens with the MSC firmware example from the packet 'lpcopen_2_12_keil_iar_keil_mcb_4357' - I have rebuild that example a bit - changed the device class to '0xFF (vendor specific)' and removed all the MSC Bulk packets processing. Result is the same, so I don't think I have screwed up the LPC device driver, moreover MacOSX and there Linux PCs work just fine. 

  Has anyone come across this problem? It makes it impossible for me to deploy the device - it just wont work on some hosts for an unknown reason. I will appreciate any ideas how to deal with this. Thanks.

[lpcware]

Content originally posted in LPCWare by bavarian on Fri Sep 26 03:12:34 MST 2014
This sounds like an electrical problem on the USB connection. The existing USB 3.0 implementations sometimes show a different behavior compared to mature 2.0 implementations. Did you try it with known good and short cables?
Your test with the 2.0 hub in between shows that the problem is related to the port of the ASUSTek motherboard.

One thing you could test on MCU side:

Locate your code into SRAM or into external SPI flash memory and switch off the flash blocks in registers FLASHCFGA and FLASHCFGB.
The reason is that the flash controllers are connected to the same power domain as the high speed PHY, during flash activity the quality of the PHY degrades slightly. This can be observed in the eye diagram. If you don't use the flash you get the best quality out of the PHY and therefore you might pass the test.
But this means in general that the connection between the two PHYs in the MCU and the PC is not good enough, or alternatively the PHY in the PC has a quality problem.

Regards,
NXP Support Team