)]}'
{
  "commit": "a85a6afc6d98726f5edfb2d7606527c87c963dba",
  "tree": "9dfea7e09f90b56e7fc9445edeb05299fa75cf8e",
  "parents": [
    "2fda873fa5f6ef0c893f4f138b5c54e49c24e0a9"
  ],
  "author": {
    "name": "hathach",
    "email": "thach@tinyusb.org",
    "time": "Mon Aug 17 01:02:07 2026 +0700"
  },
  "committer": {
    "name": "hathach",
    "email": "thach@tinyusb.org",
    "time": "Tue Aug 18 22:07:49 2026 +0700"
  },
  "message": "usbd: handle a refused transfer without halting, and report it\n\nA refused transfer is a recoverable condition - a new setup superseding a\ncontrol response, for instance - rather than a bug, but every failure path\ntreated it as one. TU_ASSERT carries TU_BREAKPOINT, which is gated on a debugger\nbeing attached rather than on CFG_TUSB_DEBUG, so on a rig where a probe is\nalways attached it halted the CPU even in release builds. Use TU_VERIFY on the\ncontrol transfer paths, including the multi-packet data stage continuation, and\ndrop the breakpoint from the endpoint transfer failure arm, which already marks\nthe endpoint ready again so the next transfer can proceed.\n\nThe result of usbd_control_xfer_cb() was separately dropped on the floor,\nleaving EP0 neither armed nor stalled and nothing recorded. It is logged now,\nand deliberately not stalled: a DCD refuses an EP0 prime when a newer setup is\nalready latched, and EP0 stalls are cleared by hardware when that setup arrives,\nso a stall issued here would land after the auto-clear and stall the transfer\nthat superseded this one. The pending setup re-drives EP0 by itself.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7215a8dc5ce3a690982235c45c1aaec23fcbb536",
      "old_mode": 33188,
      "old_path": "src/device/usbd.c",
      "new_id": "e84d72fa446363e02f1c54939ca93b8b25c69c25",
      "new_mode": 33188,
      "new_path": "src/device/usbd.c"
    }
  ]
}