Did you try hooking up a CATC analyzer to see what is happening at the bus level?
A packet larger than the requested size can also fail. Are you taking care that the packet size and the buffer allocated on the host app is greater than or matching in size?
Yes, on the host side everything looks to be in order. I'm requesting exactly the amount I need, it just comes up short. I even tried using the simple XferData API with one lump sum, and I had the same issue there. I guess it's worth it rounding up to the next 512B boundary and seeing if that makes a difference. If that does work, that would be an indication that I'm sending too much data, correct?
I haven't looked with a CATC yet (it'll take me some time to find it). I will check with a software sniffer tomorrow.
As an aside to this question, how can I recover the FX2LP EPs from this state? When I try to repeat a transaction after this happens, it seems to be sort of stuck, but I'm not sure whether it's on the USB side (NAKing) or on the FIFO side (asserting empty/full). I haven't found a reliable sequence yet where all the endpoints are flushed completely and can accept new transactions - right now I just power-cycle the board, which is rather inconvenient.
Thanks for your help so far.
Forgot to ask this,
What is the endpoint type (bulk, iso) you're using?
Does the xferdata fail immediately or does it wait till the timeout period?
What kind of hang are you observing when this happens?
Bulk EP, two buffers deep.
XferData fails immediately.
Not sure what you mean by "what kind of hang" - as far as the device being unresponsive, I'm guessing it has to do with stale data in the endpoint buffers. Like I said, I'm not sure if it's on the FIFO side or on the USB side, but for whatever reason, I can't communicate over the Bulk EPs anymore. The initialization/priming sequence of the FX2LP has always been black magic to me, so for now power-cycling seems to be the way to go. When I deploy this thing, I'm going to need a more reliable solution though.
Xferdata returns immediately if the endpoint STALLs or doesn't respond at all (No ACK, NAK nothing... In FX2LP this happens only if you're trying to talk to a disabled endpoint) or packet larger than the requested size is sent. If the device NAKs then Xferdata will wait till the timeout.
When you say device becomes unresponsive do you mean the next xferdata requests time out or do they return immediately with failure??
Note: Set the timeout to higher value so that the effect is observable.
Anand, thanks to your comments I was able to track down and solve the problem. Here's what happened:
1. I changed my host app to round the data transfer up to the nearest 512B. This worked, and I found that a few extra bytes are transferred sometimes (e.g. 10000004 bytes instead of 10000000).
2. I added a counter at the FIFO interface on the FPGA, and indeed the right amount of data was being written.
3. I changed the logic for generating SLWR to not assert it when the FIFO FULL flag was set (even though this shouldn't really alter the behavior in my opinion). This solved the problem - now the exact amount of data is transferred.
Thanks again for your help!