Hi-

I'm working with an FX2LP EZ-USB development kit.  I'm using VS2010 in an MFC C++ project, via cyapi.lib.  I have a question about XFerData() on a Bulk Endpoint.  I have a tight loop that reads single bytes from an in endpoint.  I have set the timeout to '0' and I sometimes get a "false" return code, but the "bufLen" variable shows that data was returned.  The lastError value is set to 997 (ERROR_IO_PENDING).  My question is "What IO is pending?". I have other things to do in the loop, so I would just like to see if the data is ready to be sent upstream to the PC.  I expected either a false with bufLen set to '0', or true with a non-zero bufLen.  I don't know how to interpret the mixed case.  The buffer I supplied is 512 bytes big, and I set bufLen to 512 before I make the call.  Below is a simple portion of the code.

I have not looked at this at a hardware level yet, as it seems like the data does come across.  The hardware is set to send up 1 or 2 byte packets.

unsigned char inStatusBuff[512];

...

m_StatusInEndpt->TimeOut = 0;

bool bSuccess = false;

char 

    while (!m_bClosing) {

...

lCount = 512;

//m_StatusInEndpt is a Bulk In Endpoint

bSuccess = m_StatusInEndpt->XferData(inStatusBuff,lCount);

m_StatusInEndpt->LastError;

if(!bSuccess && lCount != 0)

{

m_ErrorCount++;

CString strError;

strError.Format("Error code: %d\r\n",m_StatusInEndpt->LastError);

m_printf(strError);

}

...

    }

 Hi,

The value that you need to pass in the variable "lCount" is the same as the number of bytes. i.e. in you application you need to transfer only 1 or 2 bytes for every transfer, thus assign lCount = 1 (or 2), instead of 512. Since you were specifying 512, it was expecting 512 bytes of data, and thus reporting IO_PENDING error, even though it receives the 1 (or 2 ) bytes of data. 

Regards,

Gayathri

 Hi-

Thank you for your reply.  The problem ended up going away when we modified the hardware layer that was committing packets on the other side.  I'm not sure it was the cause, however one of the major things we found was that we disallowed zero length packets, however we were still commiting empty packets to the part.  The above code is working fine now, it returns true if there is data(and changes lCount to tell me how much data was received), and false when there is no data.  I set up all of my buffers to be a full 512 because I noticed that if you make a request for data with a size less than the packet coming up from the part, the USB "in" will fail.  I noticed this same thing in your provided loop back hardware using the test tools provided.  If you send down a bulk packet of 2 bytes, then request only a single byte the transmission will fail even though there is data.  The only way that I found around this was to always ask for a packet size (512) worth of data.  In my target application I won't always know how much data will be available, so I always ask for a full packet.

Thanks again

-b

I also made a small change to the code posted above, I changed the timeout from '0' to '10'.  I now have a different question, is there a way to have XFerData return after a single USB packets worth of data has come across? When I set the timeout back down to '0' and started sending larger packets I would still receive 997 (I'm assuming since the packets are taking too long to transfer?)  I'd like to wait for a full USB packet, but no longer.

 Hi,

XferData will return either after Timeout, or when transfer completes successfully, whichever completes first.

Regards,

Gayathri