Aw: FT232H, asynchronous fifo, read error -8 when long byte sequence is supposed to be received

[kormi@xxxxxxx]

I (kind of) solved the issue. For anyone else trying something similar:
The -8 is a libusb error code meaning bulk transfer overflow. This does not 
happen anymore (in my case) with a read chunk size of 16384. No idea why.
 
With these setting I can read from the FPGA and the FT232H in asynchronous fifo 
mode at roughly 3 MByte/s from a PocketBeagle - and I do not loose one single 
byte!

Thanks and regards,

Thomas 

Gesendet: Freitag, 03. April 2020 um 16:02 Uhr
Von: kormi@xxxxxxx
An: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Betreff: FT232H, asynchronous fifo, read error -8 when long byte sequence is 
supposed to be received

Hi,
 
I am using the asynchrounous 245 fifo mode on a FT232H. I used the Windows 
program FT_Prog to enable this mode on the eeprom. According to the datasheet, 
without further setting of the bit_mode the chip is now in this asynchronous 
mode. I see with the HTerm program that data is sent and received accordingly.
 
The system is intended to work with a Linux ARM board with the C++ wrapper of 
libftdi. I use version 1.4. Data is received and sent correctly, unless a large 
sequence of data is supposed to received by the software, i.e. the hardware 
sends e.g. 1000 bytes while respecting the TXEn line. This package size is set 
on the hardware side, not in the software.
The problem is, that I get an error on the read function when the package size 
exceeds 1500 bytes. Below this, it works fine. I played with the 
read_chunk_size without any effect. Disturbing is, that HTerm receives all data 
accordingly, even with very large byte sequences.
 
This is the relevant code:
 

fStatus=fFD.open(vid,pid,it->description(),it->serial());
cout << "opened with " << fStatus << endl;
//0 -> okay
fStatus=fFD.reset();
//0-> okay
 fStatus = fFD.set_flow_control( SIO_RTS_CTS_HS);
//needed?? 0-> okay
fStatus = fFD.set_latency(16);
//Crash with 2, 16 okay. Is this something to play with?
fFD.set_usb_read_timeout(1500);
fFD.set_write_chunk_size(1);
//only single characters are written to the device, then it is supposed to 
respond. Works if set to 1.
fFD.set_read_chunk_size(1000);
//played with this one. Does not seem to change much. I even removed this line, 
the error still happens.
uint8_t buf[1];
buf[0] = 0x7F;
fStatus = fFD.write( buf, 1);
//special character sent to device. Now it starts sending a large package of 
bytes. The TXEn line is respected by the other end
uint8_t* buffer = new uint8_t[2*gl];
int bytes=0;
int increment=0;
while(bytes<2*gl) {
                increment=fFD.read(&buffer[bytes], 2*gl-bytes);
                //here I receive: -8
                //it has been tried to just read some bytes at once, with the 
same effect. The only thing that matters is the number of bytes the hardware 
sends upon receiving the 0x7F character.
                if(increment<0) {
                      cout << "reading error: " << increment << endl;
                }
                bytes+=increment;
}
 
I would be very happy if anyone can give me a hint what is going wrong, i.e. 
how to interpret the -8 error code and what to change to get this working (and 
why this works in HTerm?)
 
I would change to the kernel serial driver, however, it is intended to switch 
from asynchronous to synchronous fifo mode in the future. Therefore I would 
like to stay with libftdi.
 
Thank you very much for your help and hints!
 
Thomas 
------------------------------------------------------------
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to 
libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx[mailto:libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx]


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx