More XferData() fun

[Anonymous]

I'm finding that my current console application sometimes hangs. It uses XferData() in the C++ CyAPI library. If I then execute the Control Center application that uses the C# BeginDataXfer, FinishDataXfer CyUSB.dll I can conduct data transfers as usual. Terminate the Control Center program and run my C++ application again and it dones nothing and hangs. Go back to the Control Center application and I can do xfers as usual. I've been having to toss the first FX3 dma buffer size worth of data because it is always stale. I don't know if that is connected to my issues. What is certain is that for some reason Cypress has no examples using XferData() to use as a sanity check.

[Anonymous]

Correction:

   

What I posted before isn't quite correct. Only one endpoint is getting hosed by XferData() and xfers from that endpoint fail to work with either my application or the Control Center. My application does seem to do xfers to the other endpoints but when it tries to do a bulkin from the hosed endpoint it never returns from XferData()... and absolutely no data is being transferred. In fact the dma ready flag is not being set. During all of this testing today the dma ready flag associated with the endpoint from which XferData() doesn't return is NOT set.  My FPGA design is predicated on the premise that the dma flags are de-asserted only when a transfer has completed or has been aborted. Sorry for the confusion.

   

I may be missing something with the CyAPI library usage but it sure would be nice if calls to XferData() always returned and indicated if the library code was still waiting to xfer more data and how many bytes it was expecting. I've had subtle timing issues with the signals driven by the FPGA that resulted in 1 too few words being transferred but this has always resulted in the associated flag not getting de-asserted and or the FPGA not indicating xfer_complete. This is not happening currently suggesting a problem external to either the FPGA or FX3 firmware.

[Anonymous]

Update:

   

I thought that I'd be smart and check Nstatus prior to calling XferData() since it doesn't always play nicely. I re-booted my computer and made the changes to my console application. Nothing ( that is no return and no error message ) after the first check of Nstatus for the affected endpoint. I switched back and re-loaded the FPGA and FX3 firmware and ran the application once more. This time I got a few EP1 bulkin transfers ( the endpoint that was failing ) and then a few more EP2 bulkin transfers with no EP1 bulkin transfers between them. I know what the application is doing and it isn't doing that... I have seen this before where calls to xferData() for a particular endpoint fails to set the dma ready flag but usually XferData() fails to return and the application hangs. I am pretty confident in saying that calls to XferData() sometimes hangs, sometimes does no data transfers but returns, and sometimes does fewer than the requested data transfers. Morever, what ever the fault is it seems to live beyond the life of the application causing it. Sure would be nice if the CyAPI library had a few more diagnostic procedures to add to the toolbox.

[Anonymous]

The resolution:

   

I caught the dma ready flag for the bulkin data transfer for the endpoint that was failing being asserted for a few clock cycles after de-assertion which is not proper behavior for the FX3. The problem was timing of control and data relative to the PCLK on the single bulkout to another endpoint that preceded it. Once the FPGA control signal output timing was corrected the problems went away. My first thought should have been that when otherwise working software starts acting bizarrely to revisit potential timing violations of the hardware. This is a good reason for having test points on the target hardware, which I don't have.

[Anonymous]

Hi,

   

Thanks for updating this thread with your findings.

   

Thanks,

   

sai krishna.