There is a fairly steep learning curve in switching to libftdi (which is built on top of libusb, both of which must be understood), but I've performed enough preliminary tests at this point that I am confident that this approach will work for me.  Thanks for your help in pointing this out.

Dave

Miriam -

I realize that this thread is now over two months old but I'm wondering if any progress has been made on this issue?  The reason I ask is that I'm facing a similar problem - data loss/corruption originating on a board with an FT232H operating in 245 FIFO mode (async) and connected to a Raspberry Pi (3B).  Like you, my application on the Pi is written in C, uses the D2XX library (arm-v6-hf-1.4.6) and is compiled with GCC.  Also like you, the code runs fine on a Windows 7 64-bit system.

My application is a data logger and the hardware consists of a small board which takes as input a 30MHz Manchester encoded bit stream.  A CPLD decodes this bit stream back into 8-bit data and strobes it into the FT232H (and yes, the CPLD monitors the TXE# line to prevent overruns).  The data then runs over a short USB cable to the Pi which accumulates it and writes it out to an attached 1TB USB drive.  Each file accumulates roughly 10MB before it is closed and the next one opened.  For troubleshooting I have a logic analyzer monitoring the 8 data lines and WR# between the CPLD and the FT232H and a hardware USB capture unit between the data logger board and the Pi.  Thus, I can monitor the data between the CPLD and the FT232H and between the FT232H and the Pi.  This, along with the output file, allows me to monitor data from where it's originally generated to where it's finally stored.

After realizing that this seemed to be a Pi only related problem, I conducted a series of tests.  In the first one I reprogrammed the CPLD to simply generate a continuously incrementing byte pattern.  This was written into the FT232H at a maximum rate of 7.5MHz, pausing only to wait on TXE# if needed.  The Pi code consisted of a loop which did an FT_Read() for 64KB and then checked the data.  Not everything was checked - only the first and last bytes in each buffer.  If there was any data loss, it would have to be in multiples of 256 bytes to avoid detection.  This test successfully transferred over 15GB of data without any detected errors before I stopped it.  The actual throughput on this turned out to be closer to 7MB/sec based on the amount of data received by the application and the time over which the test ran.

The next test extended the first test to write the incoming data to disk in 10MB files.  The Pi program was modified to do this in two threads - the input thread which accumulated the data and an output thread which wrote this to disk.  This was necessary as the fwrite() can become lengthy if the internal buffers fill up and must be flushed to disk.  I found that I was able to sustain just over 2MB/sec with this configuration.  This test ran for several hours before I manually stopped it.  Had the input thread detected an error it would have aborted the test immediately.  Further, I wrote a small script to check the output files and no corruption or dropped data was detected in any of them.

Next, I performed a final test where the CPLD was reprogrammed back to the original Manchester decoding configuration and, instead of running continuously, only a 4MB sample of data would be accumulated from the bit stream and written to disk.  This size was chosen because the depth of my logic analyzer is only 4MB and it allowed me to capture all of the decoded data generated by the CPLD.  This past weekend I ran over a half dozen tests.  The data rate of the actual logging data is only around 100KB/sec so each test only took about 40 seconds.  Each disk file was found to contain anywhere from 1 to 7 errors (one file actually made it all the way through without errors) so, while the test itself ran quickly, analysis of logic analyzer, USB and disk files could take hours to determine exactly what had happened and where, so this limited the number of tests run.

What I found was that the errors could be summarized in three categories.  The first was the injection of the byte pattern "0x32 0x00" into the data stored on disk.  While this was not present in the logic analyzer trace, it was present in the USB analyzer files.  Each high-speed data packet typically consisted of 512 bytes of data.  The first two were "0x32 0x00" followed by 510 bytes of data that were generated by the CPLD.  Somehow the FT232H and D2XX library seem to be getting out of sync such that this 2-byte header ends up in the data being returned from the FT_Read().  The second catagory consisted of dropped data, anywhere from a few dozen bytes to over 1KB, where the data from the CPLD was also seen to correctly cross the USB and subsequently be dropped somewhere between the USB port on the Pi and the appliction.  The final category also consists dropped data but in this case it was dropped in the FT232H as the data from the CPLD was NOT seen on the USB trace.

I don't know if any of this information is helpful to you or if you have already resolved your issue.  In my case, my final application absolutely requires a data logger and I have spent a lot of time getting this far.  I'm really hoping this can be resolved, otherwise I'm faced with starting over from scratch and developing a board that does not use USB to transfer the data from the logger board to the Raspberry Pi.

Regards,
Dave