question on the details of an FX2 bulk read response from host

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 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

0 Likes
3 Replies
Anonymous
Not applicable
      Hi Scott,   
   
     You need not to configure the endpoint to respond it differently to a bulk read request, based on EP condition and received data  it will automatically issue a STALL, NAK  or data, this is a USB2.0 specisfication requirement.   
   
        
   

 

   
     When the host is ready to receive bulk data, it issues an IN token(Bulk Read).  The function endpoint responds by returning either a data packet or, should it be unable to return data, a NAK or STALL handshake.     
   
     NAK- indicates that the function is temporarily unable to return data,    
   
     STALL- indicates that the endpoint is permanently halted and requires USB System Software intervention.     
   
     ACK- If the host receives a valid data packet, it responds with an ACK handshake.    
   
      If the host detects an error while receiving data, it returns no handshake packet to the function.   
   
    
   
   

 

   
     When the host is ready to transmit bulk data(Bulk Write), it first issues an OUT token packet followed by a data packet .  If the data is received without error by the function, it will return one of three (or four including NYET, for a device operating at high-speed) handshakes:   
   
     •  ACK indicates that the data packet was received without errors and informs the host that it may send the next packet in the sequence.   
   
     •  NAK indicates that the data was received without error but that the host should resend the data because the function was in a temporary condition preventing it from accepting the data (e.g., buffer full).   
   
     •  If the endpoint was halted, STALL is returned to indicate that the host should not retry the transmission because there is an error condition on the function.   
   
     If the data packet was received with a CRC or bit stuff error, no handshake is returned.   
   

 

   

 

   
    Regards   
   
    Prajith   
0 Likes
Anonymous
Not applicable

 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

0 Likes
Anonymous
Not applicable

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

0 Likes