Sorry, I ended up resolving this but never posted the final results.

It turned out to be a problem with the hub IC.  It was built into the CPU SOC and it would randomly lower the output voltage of the D+/D- signals sometimes so that the FTDI couldn't discern the signal.  We never got the vendor to admit why.  We eventually got a work around in the bios by changing the hub from xHCI to EHCI Controller.  The hub had USB 3.0 ports which we weren't using and I think they were confusing the 2.0 ports by trying to negotiate sometimes?  Not sure.  By using the EHCI controller it forced the USB 3.0 ports off and the problem went away.

Hi,
  I'm not the original poster, but I'm having the same problem.  I'm using FTD2XX Library version: 00010112 with the FT232HL.  I've tried setting the timeouts to 50000 and the problem still occurs. 

My application is programming an FPGA.  I use the FTDI in FIFO mode to talk to a CPLD which reads the data from the FTDI and then writes it out to the FPGA configuration pins.  It's a custom implementation; it doesn't follow the FPGA configuration examples that FTDI provides.  The OS in my case is linux.  The latency is not important but the bytes must all arrive correctly without any data loss or corruption or else the FPGA configuration will fail.

Resetting the USB hub can clear this error condition and make the configuration pass every time.  But when the hub is in this 'bad' state, the FPGA configuration fails 2 out of 3 tries.

When the FT_Write fails, there's no error code but 0 bytes were written.  If I dump all the USB accesses from the linux kernel (https://technolinchpin.wordpress.com/2015/10/23/usb-bus-sniffers-for-linux-system/) I see a EPROTO protocol error from the bulk OUT transfer that fails.  I don't see that error when the configuration succeeds.  I tried resending the failed block and also just ignoring the failure but both still fail to configure the FPGA.  I also tried periodically checking FT_GetStatus to see if there were bytes in the queue but it always read 0.

I've also tried using the libftdi driver and I get a similar problem but it doesn't error on the write.  It still gets the EPROTO in the linux kernel and the FPGA configuration fails so I suspect that driver just ignores whatever error is happening.

This problem just showed up recently, coinciding with a new CPU model.  This design was used with an older slower CPU without problems.  I think the faster CPU might be writing too fast.  What is the flow control method for OUT data?  How is the FTDI supposed to throttle the CPU?  Does the FT232H generate USB NAKs and/or NYETs?

thanks,
Gabe