usbd: handle a refused transfer without halting, and report it

A refused transfer is a recoverable condition - a new setup superseding a
control response, for instance - rather than a bug, but every failure path
treated it as one. TU_ASSERT carries TU_BREAKPOINT, which is gated on a debugger
being attached rather than on CFG_TUSB_DEBUG, so on a rig where a probe is
always attached it halted the CPU even in release builds. Use TU_VERIFY on the
control transfer paths, including the multi-packet data stage continuation, and
drop the breakpoint from the endpoint transfer failure arm, which already marks
the endpoint ready again so the next transfer can proceed.

The result of usbd_control_xfer_cb() was separately dropped on the floor,
leaving EP0 neither armed nor stalled and nothing recorded. It is logged now,
and deliberately not stalled: a DCD refuses an EP0 prime when a newer setup is
already latched, and EP0 stalls are cleared by hardware when that setup arrives,
so a stall issued here would land after the auto-clear and stall the transfer
that superseded this one. The pending setup re-drives EP0 by itself.

src/device/usbd.c

diff --git a/src/device/usbd.c b/src/device/usbd.c
index 7215a8d..e84d72f 100644
--- a/src/device/usbd.c
+++ b/src/device/usbd.c
@@ -757,7 +757,14 @@
         _usbd_dev.ep_status[epnum][ep_dir] &= (uint8_t) ~(TU_EDPT_STATE_BUSY | TU_EDPT_STATE_CLAIMED);
 
         if (0 == epnum) {
-          usbd_control_xfer_cb(event.rhport, ep_addr, (xfer_result_t) event.xfer_complete.result, event.xfer_complete.len);
+          // Not stalled on failure: a DCD refuses an EP0 prime when a newer setup is already
+          // latched, and EP0 stalls are cleared by hardware when that setup arrives - so a stall
+          // issued here lands after the auto-clear and would stall the transfer that superseded
+          // this one. The pending setup re-drives EP0 by itself.
+          if (!usbd_control_xfer_cb(event.rhport, ep_addr, (xfer_result_t) event.xfer_complete.result,
+                                    event.xfer_complete.len)) {
+            TU_LOG_USBD("  Control stage not continued\r\n");
+          }
         } else {
           usbd_class_driver_t const* driver = get_driver(_usbd_dev.ep2drv[epnum][ep_dir]);
           TU_ASSERT(driver,);
@@ -875,10 +882,10 @@
     if (ctrl_xfer->data_len > 0U) {
       TU_ASSERT(buffer);
     }
-    TU_ASSERT(data_stage_xact(rhport));
+    TU_VERIFY(data_stage_xact(rhport));
   } else {
     // wLength == 0: Status stage is always IN per USB 2.0 §9.3.1
-    TU_ASSERT(status_stage_xact(rhport, TU_EP0_IN));
+    TU_VERIFY(status_stage_xact(rhport, TU_EP0_IN));
   }
 
   return true;
@@ -929,7 +936,7 @@
     }
 
     if (is_ok) {
-      TU_ASSERT(status_stage_xact(rhport, ep_status));
+      TU_VERIFY(status_stage_xact(rhport, ep_status));
     } else {
       // Stall both IN and OUT control endpoint
       dcd_edpt_stall(rhport, TU_EP0_OUT);
@@ -937,7 +944,7 @@
     }
   } else {
     // More data to transfer
-    TU_ASSERT(data_stage_xact(rhport));
+    TU_VERIFY(data_stage_xact(rhport));
   }
 
   return true;
@@ -1608,10 +1615,12 @@
   if (dcd_edpt_xfer(rhport, ep_addr, buffer, total_bytes, is_isr)) {
     return true;
   } else {
-    // DCD error, mark endpoint as ready to allow next transfer
+    // Driver refused the transfer, mark endpoint as ready to allow next transfer. This is a
+    // recoverable condition (e.g. a new setup superseding a control response), not a bug, so
+    // do not break into the debugger - TU_BREAKPOINT() halts the CPU whenever a probe is
+    // attached, which on a test rig is always.
     _usbd_dev.ep_status[epnum][dir] &= (uint8_t) ~(TU_EDPT_STATE_BUSY | TU_EDPT_STATE_CLAIMED);
     TU_LOG_USBD("FAILED\r\n");
-    TU_BREAKPOINT();
     return false;
   }
 }