3 Replies Latest reply on Nov 2, 2018 6:36 AM by enro_3634616

    Fx3 -  Communication stops working after buffer fillup (libusb/linux)

      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.

         

      To reproduce:

         

      * 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?

         

       

         

      Best Regards

        • 1. Re: Fx3 -  Communication stops working after buffer fillup (libusb/linux)

          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.

             

          Did you ever solve your problem?

          • 2. Re: Fx3 -  Communication stops working after buffer fillup (libusb/linux)

            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) )

            • 3. Re: Fx3 -  Communication stops working after buffer fillup (libusb/linux)

              Hi,

               

              I have a similar problem:

              I am using the cypress FX3 and libusb on linux. The FX3 is connected to an FPGA which sends a data streaming on the USB connection.

              It is also possible to read simple user-configuration registers from the FPGA through the USB channel.

               

              I am actually able to read those user-configuration register (each register is 32 bit) but, as soon as I enable the data stream, libusb function returns a timeout error without reading anything.

              After the error, I need to reset the FX3 to bring up again the communication.

               

              The strange thing is that the error pops up when the FX3 is connected to a USB3.0 port. Using a USB2.0 port, everything works fine

               

              Did you solve your problem? Could you share your solution?

               

              Thanks,

              Enrico