Requests following a rejected SETUP requests failed too, which sometimes

produces user-visible errors and may confuse implementations. (E.g., when
probing for an unimplemented feature and subsequently being greeted by a
timeout.)

- fw/comon/usb.c (handle_setup): set SOPRDY when answering a request error
  with a stall, according to the example in AN139. This seems to eliminate
  the timeouts observed in requests following after bad requests.
- fw/boot/boot.c (run_payload): described how the host is expected to
  respond to the device resetting its USB stack

fw/boot/boot.c

@@ -71,6 +71,15 @@ void run_payload(void)
 	/* Restart USB */
 	USB0XCN = 0;
 
+	/*
+	 * The USB host must detect a disconnect (pull-ups absent) within 2 and
+	 * 2.5 us according to parameter Tddis in table 7-13 on page 186 of the
+	 * Universal Serial Bus Specification Revision 2.0.
+	 *
+	 * If our application calls usb_init really really quickly, we may need
+	 * an extra delay here.
+	 */
+
 	debug("launching payload\n");
 
 	__asm