Vojtech Michalek wrote: > Thanks for the tip, I tried it, but it was not the cause. I have performed > additional transfers totalling several tens of GB and have not realize the > cause. With respect to low error rate, it is hard to avouch what it > influences; however, it seems it is dependent on how the output of reading > program (both "cat" and a program based on libftdi) is handled, i.e., if it > is just redirected to a file, or pipelined and duplicated with tee to an > output file and a data check program. For now, I suppose the missing blocks > may be caused just by USB and Linux "non-realtimeness".
The chip has a 4kB buffer, so writing at 300kBps means you'll run into problems if something stalls for as little as 13ms. Make sure you're paying attention to signals like TXE# and not writing to the chip when its internal buffers are full; that can easily cause lost or corrupted data. -jim > On Fri, Apr 5, 2013 at 7:27 PM, Jim Paris <[email protected]> wrote: > > > It seems strange that both libftdi and the kernel driver would have > > the same problem. Maybe try plugging in the device and going through > > the Linux driver without running any libftdi code first, just in case > > libftdi itself is configuring the device in a way that causes > > problems. > > > > -jim > > > > Vojtech Michalek wrote: > > > In order to try to get additional information on the errors origin, I > > > decided to replace libftdi programs with an alternative ones using > > > proprietary ftd2xx library. I did not expect any significant change, but > > it > > > has transferred more than 4GB without any error so far. > > > > > > Vojta > > > > > > > > > On Thu, Apr 4, 2013 at 5:26 PM, Vojtech Michalek <[email protected] > > >wrote: > > > > > > > Hi all, > > > > > > > > during my measurements, I encounter rare errors in data stream (i.e., > > > > approx 10 errors in 1GB data). I use FT2232H in standard asynchronous > > > > serial mode at 3MBd, transmitting approx. 300kBps. I try to debug it > > while > > > > sending incrementing 16bit number in a loop, so that I could check what > > > > happens with data. From time to time a data block of various size is > > > > missing. > > > > > > > > The same behaviour is reproducible with two topologies: > > > > 1) transmitter: LPC1343 microcontroller, receiver: FT2232H > > > > 2) transmitter: FT2232H, receiver: another FT2232H > > > > > > > > In order to exclude I do something wrong with libftdi, I try to read > > the > > > > data from FT2232 with linux command "cat" (and write with system > > command > > > > write for the second topology). I got similar error rate as with > > libftdi > > > > functions but with an additional strange effect. Two zero bytes are > > stuffed > > > > in the data stream with the following "structure": single zero byte, > > after > > > > next correct 511 bytes comes second zero byte, and after next correct > > 3587 > > > > bytes (really strange number to me) is the missing block of data. Then > > > > several hundreds of MB of correct data follows before next error > > occurs. > > > > > > > > Have you any hint what I could try to make the communication more > > reliable? > > > > > > > > Thanks, > > > > Vojta > > > > > > > > > > > > > -- > > > libftdi - see http://www.intra2net.com/en/developer/libftdi for details. > > > To unsubscribe send a mail to > > [email protected] > > > > -- > > libftdi - see http://www.intra2net.com/en/developer/libftdi for details. > > To unsubscribe send a mail to [email protected] > > > > > > > -- > libftdi - see http://www.intra2net.com/en/developer/libftdi for details. > To unsubscribe send a mail to [email protected] -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
