USB 2.0 device doesn’t return an expected handshake packet during a control transfer, the host retries. On receiving no response after a (typical) total of three tries, the host notifies the software that requested the transfer and stops communicating with the endpoint until the problem is resolved.

The two retries include only those sent in response to no handshake at all. A NAK triggers a retry but doesn’t increment the error count.Control transfers use data toggles (USB 2.0) or Sequence Numbers (Super- Speed) to protect against lost data. In the Data stage of a USB 2.0 Control read transfer, on receiving the data from the device, the host normally returns ACK and then sends an OUT token packet to begin the Status stage. If the device for any reason doesn’t see the ACK returned after the transfer’s final data packet, the device must interpret a received OUT token packet as evidence that the Status stage has begun.

Devices must accept all error-free Setup packets. If a new Setup packet arrives before a previous control transfer completes, the device must abandon the previous transfer and start the new one.

A USB 2.0 device has these responsibilities for transfers on a control endpoint:

• Send ACK in response to every Setup packet received without error.
• For supported control write requests, send ACK in response to received data in the Data stage (if present) and return a ZLP in the Status stage.
• For supported control read requests, send data in response to IN token packets in the Data stage and ACK the received ZLP in the Status stage.
• For unsupported requests, return STALL in the Data or Status stage.