Hi

If I send let's say 128 Bytes upstream from the slave fifo interface by pulling low PKTEND and then want to read 12 Bytes (len=12) using XferData(buf,len), the upstream link stalls until the FX3 is reset.

I can understand that XferData(buf,len) returns 0 for len in this case because it is less than the packet size. Nevertheless, I was surprised to learn that from this instant I was not able to read data at all, even if len>=128 (larger or equal than the packet size). I was required to reset the FX3 to get the upstream link working again.

Has somebody observed this behaviour as well? I am using the V1.0 SDK.

-Silvio

What is happening here is when you request for 12 bytes you've allocated space for 12 bytes and the device is sending 128 bytes which will cause overflow. Even then I wouldn't expect it to stall the pipe.

Have you tried calling Abortpipe() when this occurs?

Have you tried using control center to see if the behavior is the same?

Regards,

Anand

I get the same issue when using the ControlCenter. The error reported is:

"BULK IN transfer failed with Error Code:997"

Abort() does not help to unstall the pipe. Reset() does but then I am loosing data. Please advice if you can reproduce the error.

-Silvio

 Hi!

I meet the similiar problem with cypress CY3014. Have you solved your problem?? Wish to connect with you . Many thanks1

Dekui

Unfortunately I was never able to solve this problem. Even Cypress was not able to help me. To get around this problem I do not use the PKTEND# signal anymore and make sure that there is always 1024 Bytes transferred at once (insert padding data if necessary).

-Silvio

Hi Silvio,

Here is how I hope to use pktend. For example if I want to send 8292 bytes (8 x 1024  + 100). The software XferData(buf,len) asks for 9216 bytes (9 x 1024). At the FX3 side the FPGA will write 8 x 1024 bytes to the FX3, it will then write 100 bytes and assert pktend. This 100 bytes will go to the host which then sees an incomplete packet which means this transfer is complete. Is this not a better way of doing things than having to pack your data up to 1024 bytes. I've tested the above process and it seems to work.

Sodafarl

Hello Sodafarl

But when you request more bytes than there are available, doesn't XferData() block until the timeout is reached? Ok, you could set the timeout to 0 but this brings for sure other disadvantages.

Just now I tried to request more bytes (available: 16384, requested: 17408) on my machine and stil I got 0 Bytes back. However, this was without using PKTEND# and using overlapped transactions. Nevertheless, I expected to get at least the 16384 Bytes back which wasn't the case.

-Silvio

Silvio,

Yes, if you ask for more bytes than are available then XferData will block, so for transfers that are made up of complete packets ask for exactly the right number of bytes but for transfers that contain an incomplete packet XferData should round up the number of bytes to the next packet size and then on device side use pktend to kick the small packet across USB to XferData. Because it  gets a small packet the driver knows this transfer is complete and XferData returns with the exact number of bytes you sent - not the number that was asked for in the XferData(buf,len).  In the example you give if you want 16384 or 17408  then XferData should ask for this but if it is a number in between then set  XferData to ask for 17408, transfer 16 packets of 1024 and then after  the smaller packet  is in FX3 use pktend to send across USB.

Sodafarl

Ok, this makes sense. But what I do not understand is why XferData() reads 0 Bytes if I request more bytes than are available in the input buffer. I would expect that after the timeout is reached, XferData() returns all bytes in the buffer and modifies the len parameter accordingly.

In addition, it makes absolutely no sense that XferData() stalls if there is more data in the input buffer than requested.

-Silvio

We are experiencing the same problem. Any good solutions or workarounds for this? Thank you!

Please Cypress people fix this annoying bug!

I´m not sure, but as I think, the behavior is the same as on FX2. If you request more bytes then available, the transfer only succeed if the packet end was used, even if there are n x packet size bytes available. We use packet end in nearly the same manner as on FX2 and it works without software modification (WinUSB). We request always huge data packets (1 MByte), regardless of the real ammount delivered by the FPGA. This works very well with packet end. The length variable is updated in this case.

Hi everyone,

I encountered the same problem. Cy68013's almost full flag is active, that means there are enough data(512*3) in the in endpoint buffer, but in the PC's software, xFerData's returen value len=0, and can not read in any data from cy68013, it is stange. Because, at begin, it can read in data, after transfer a while,  xFerData's returen value len=0. In the firmware, the package size is 512B. And PC's software read 1024 every time. By the way, we use PKTEND# .

Could any one solve the problem? Please give me some hints. Thanks.