Hi,

I've had a working FX2 application that sends back data from a device over a quad-buffered bulk IN endpoint (EP2) for the past year.  On the host side I'm using libusb with the usb_bulk_read() command to read the EP:

int usb_bulk_read(usb_dev_handle *dev, int ep, char *bytes, int size, int timeout);

If data in the device has not yet filled the FIFO, the above request times out (after a period of timeout milliseconds) and this is the way I always assumed it had to work.

Recently however, I've been in touch with another person who explained that upon a bulk read on their device, the device automatically sends NACK tokens until the device is ready; apparently avoiding the necessity of a time out.   

Likewise, on http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk it says:

IN: When the host is ready to receive bulk data it issues an IN Token. If the function receives the IN token with an error, it ignores the packet. If the token was received correctly, the function can either reply with a DATA packet containing the bulk data to be sent, or a stall packet indicating the endpoint has had a error or a NAK packet indicating to the host that the endpoint is working, but temporary has no data to send.

I bolded the key phrase.   So there seems to be 3 conditions, not 2 (data or timeout (stall?)).    Perhaps my endpoint is configured to respond to the host with a Stall while perhaps it's possible for me to respond with a NACK and have the host just repeatedly request the packet until data shows up?

Can anyone help me understand this, especially in the context of how I might configure the FX2 Endpoints to respond differently to a bulk read request?

Note that I've read over the TRM (not always getting every detail understood) and do see some brief discussion on the STALL bit which might be the key, but little explanation on how a Stall packet vs. NACK packet would be interpreted by the host when doing a bulk-read command...

Thanks!

Scott

 Hi Prajith,

Thanks for your response.

Just so I understand better...

If we assume I'm using AutoIn=0 for an IN ENDPOINT.   I'm arming the endpoint from within the firmware by setting the byte count register.   In that context, what actions in firmware lead to a STALL vs a NAK?

In other words, when you say "NAK- indicates that the function is temporarily unable to return data" does that mean a NAK response is given when the endpoint is not yet "armed"?   And then what programmatic state in the Cypress firmware would cause the device to respond with a STALL packet instead?

Thanks for any more info you can provide!

Best,

Scott

Hi Scott,

This notifies the host that something unexpected has happened.

STALL means that something unforeseen went wrong (probably as a result of miscommunication or lack of cooperation between the host and device software). A device sends the STALL handshake to indicate that it does not understand a device request, that something went wrong on the peripheral end, or that the host tried to access a resource that was not there. It is like HALT, but better, because USB provides a way to recover from a stall.

Regards

Prajith