tinyusb.git, branch claude/mtp-data-phase-fixes

portable/nrf5x: complete zero-length bulk OUT transfers

2026-08-17T05:17:00Z

A zero-length OUT read (e.g. the MTP driver's read for the host's terminating data ZLP) could never complete when the ZLP's EPDATA arrived after the read was armed: actual_len < total_len is always false for total_len == 0, so the handler only set data_received and the armed transfer hung forever, wedging both bulk endpoints (host sees pure NAK; EP0 stays alive). Run the 0-byte DMA in that case to drain the endpoint and complete the transfer, matching what the arm path already does when the ZLP arrives first. Found via usbmon on the HIL rig: device/mtp on feather_nrf52840_express wedged after SendObject's terminating ZLP whenever the class armed the read before the host's (NAK-delayed) ZLP retry landed - deterministic under CI load, which is why PR CI only passed this test on a re-flash retry (21.4 s vs the normal 2.2 s).

examples/mtp: clamp SendObject writes to the declared object size

2026-08-17T05:11:53Z

fs_send_object() copied every received payload to f->data using only the running offset, so a host sending more data than its SendObjectInfo declared wrote past the object and overflowed fs_buf. Clamp each copy to what remains of f->size.

class/mtp: correct data phase completion and transaction recovery

2026-08-17T05:11:53Z

The data-out phase ended before its terminating ZLP and before the application had seen the final payload, and several transaction states had no way back to idle. Reworked as one state machine: - Add MTP_PHASE_DATA_COMPLETE, entered once the data phase has fully finished - for an exact buffer-multiple data-out, only after the host's terminating ZLP - and deliver tud_mtp_data_complete_cb() from there. tud_mtp_response_send() now refuses while the phase is still MTP_PHASE_DATA: ep_out still owes the host a read at that point and re-arming it for a new command would race that read. - Arm the terminating-ZLP read before handing the final payload to the application, as the IN path already does. The 0-length read passes a NULL buffer so the payload is untouched, and claiming ep_out first means a late tud_mtp_data_receive() fails its own claim instead of breaking the driver's next step. - Honor the documented negative return of tud_mtp_data_xfer_cb() and tud_mtp_data_complete_cb() by entering MTP_PHASE_ERROR, which stalls both endpoints. This is the application's way out of a data phase now that a response cannot be sent from one. Their weak stubs return 0 so an application that does not implement them is unaffected. - Take total_len from the container header the host sends on the first OUT packet. The application can only set it up front when it knows the size (SendObject); SendObjectInfo cannot, so total_len kept the 12-byte header default and the phase ended on the first packet. - Reject a runt or misdirected container in both the command and data phases: a short packet was matched against stale buffer contents, and the failed TU_VERIFY left ep_out neither armed nor stalled. The first data-out packet previously underflowed payload_bytes instead. - Restore the previous phase when tud_mtp_data_send()/_receive() cannot claim their endpoint, so the application's fallback response is not refused by a phase the driver never actually entered. - Re-arm ep_out after MTP_REQ_CANCEL of a data phase, and defer the new-command read when ep_out is still busy with the ZLP read of an abandoned transaction: usbd_edpt_xfer() asserts on a busy endpoint, so MTP_REQ_RESET could not recover. The MTP example follows the same contract: a handler error raised mid data phase (fs_send_object_info validates the received ObjectInfo, so STORE_FULL and INVALID_PARENT_OBJECT can only be raised there) is kept and answered from tud_mtp_data_complete_cb() once the phase completes.

Merge remote-tracking branch 'origin/master' into tmp/pr3790-merge

2026-07-29T19:35:02Z

hil, ci: scope HIL builds and tests to the boards a PR affects (#3797)

2026-07-29T19:29:32Z

hil, ci: scope HIL builds and tests to the boards a PR affects Add test/hil/hil_select.py, a stdlib-only selector that maps a PR diff to the rig boards, tests and BSP families a change can affect, and wire it into CI so pull requests build and run only those. A port change picks its families' boards, a class change picks the examples enabling that class, and device/host changes prune the other role. Anything unclassified — infra, an unmapped port, a selector error — falls back to the full matrix, and push/schedule runs are untouched. Move the shared example lists to hil_examples.py; 54 hardware-free tests cover the rules.

Merge pull request #3796 from geurtv/master

2026-07-29T18:14:44Z

rp2xxx: added rp2usb_deinit() to fix 'No spinlocks are available'

Merge remote-tracking branch 'tinyusb/master' into fix/lpc43-hfp-reliability

2026-07-29T14:08:26Z

hil: split hil_test.py into hil_lock/hil_flash, add pool_check, update rig probes (#3794)

2026-07-29T10:29:59Z

test/hil: add board-pool health check, split hil_test into focused modules (#3794) Add test/hil/hil_pool_check.py: per-board rig health scan — probe presence, light-example flash (dfu_runtime; device_info + serial check for host-only boards), uid re-enumeration, safe recovery (probe authorized-toggle, board reset), verified board_test re-park, USB topology report, and a markdown summary table. Missing firmware is built on the spot (tools/build.py, idf.py for espressif, one get_deps retry); row statuses: ok, flash-failed, failed, locked. Board locks are always respected, never bypassed. Refactor hil_test.py into hil_lock.py (flock protocol, controller permits, hold/release/status CLI; replaces board_lock.py) and hil_flash.py (flashers, find_firmware, run_cmd). Update WCH probe uids and the board roster in tinyusb.json; add the hil-pool-check skill.

also added rp2usb_deinit() call to hcd_deinit()

2026-07-29T10:00:59Z

rp2xxx: added rp2usb_deinit() to fix 'No spinlocks are available'

2026-07-29T09:36:01Z