Hi all,

I'm using the CY68013A as a USB bridge to an FPGA. Right now, OUT packets are working well. When the FPGA sends IN packets, however, sometimes the last few bytes which would be a short packet are not sent. This only seems to happen with larger buffers - 5000 bytes is fine, 1MB is fine, 2MB is not, 5MB is not, and 10MB is not (9999872 bytes works). PKTEND is being asserted correctly (verified by logic analyzer) and FIFO_ADR is stable.

I'm using BeginDataXfer/WaitForXfer/FinishXfer for this operation. Curiously enough, everything works fine until the last FinishXfer fails. I have no idea why - the UsbdStatus field doesn't return anything useful. FinishXfer does return instantly, though - there's no timeout or anything like that (unlike when I didn't assert pktend previously).

No handling of the buffers is done on the device itself, and AUTOIN is set. The rest of the data that is transferred is correct, it's just cut short. I am reasonably certain that all data is being sent, and that it is correct.

Can anyone shine some light on this?

Regards,

- Marcel

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?

Regards,

Anand

 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?

Regards,

Anand

 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.

Regards,

Anand

 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!