We are running a custom firmware (1 OUT Endpoint from PC->Fx3, 3 IN endpoints FX3->PC) and communicate with the chip in linux, using libusb. Endpoint 1 IN/OUT works as kind of loop-back over GPIF, where some data processing is done on a FPGA and the data then sent back over GPIF.
We are running into some issues when sending too many packets to the OUT endpoint without reading back from the IN endpoint. At some point writing to the endpoint fails due to an timeout (which is expected, as the buffers fill up). However, after this point neither write or read operations are possible anymore. Further read operations will fail with an timeout (without reading any data), further write operations with an I/O error. To get the system working again it has to be reset.
To see if the problem was in our customization of the firmware I tried out some stock examples, using the cyusb_linux (1.0.4) tool from the linux sdk with stock examples.
As we are using Auto DMA channels, I tested the firmware/basic_examples/cyfxbulklpautoenum example. Here I can observe the same behavior.
* program the cyfxbulklpautoenum
* open cyusb_linux
* send 7 packets of any length to the device on EP 01 (no loopback)
* send another packet to the device. This operation times out
* try to read/write from the device. Reading will timeout, writing fails with an I/O error
As the error occurs for me even if I send 1 byte packets my first intuition would be that it is related to the DMA channels / commit system. On the other hand, I tested the same example on windows with the cypress drivers, where it works fine (The last write transfer will return an error, but reading is still possible after this).
Has anyone experienced a similar problem, or has an idea where the issue might be?
I have a similar problem. I used the bulk dma manual in/out, and if the host does a read (Ubuntu) before any writes, which returns zero bytes and fail, and then do a write followed by read, the read and all subsequent reads fail. But on Windows, it is fine.
I'm starting to wonder if there is some incompatibility between libusb and FX3.
Not yet, no. We just encountered it a few days ago and for now implemented a workaround in our software (limit the number of writes if there was no read).
I could reproduce your behavior with the dma manual in/out image. Strangely enough, after the first write/read fails, the next write works again (sequence: read (fail), write(fail), read(timeout), write(works), read(works) )