[jedgarpark]

What

Updates TinyUSB, the USB library, from efab607b8 to 12611f81a (current master) to get the DWC2 host abort fix.

Why

On the Metro ESP32-P4, USB host reads stopped working after a read timed out. With the M-Vave FM-1 (a USB MIDI synth), every firmware install over USB MIDI SysEx failed partway.

Link	What it is
hathach/tinyusb#4405	the bug: an aborted bulk/control IN on the DWC2 DMA host kept polling, and took the device's next data
hathach/tinyusb#4265	the fix, merged as bab06c109 (it carries hathach/tinyusb#4430)

The three TinyUSB commits after bab06c109 change only CI, test-rig and docs files, not src/.

Metro ESP32-P4, before and after

The FM-1 installs firmware over USB MIDI SysEx. The host reads until the FM-1 asks for the next block, and aborts a read that times out while the FM-1 NAKs.

Build	FM-1 directly on the Metro	FM-1 through a USB 2.0 hub
main	installs fail: reads time out after the first aborted read	not tried
TinyUSB at #4265's head (faedfe71d), 9 November	ChoralRoot → V15, V15 → SLOOP, SLOOP → V15 completed	V15 → SLOOP, SLOOP → V15, V15 → Skiff, Skiff → V15 completed
this PR, 10 November	V15 → SLOOP, SLOOP → V15 and community firmware installs completed	the same completed, plus ChoralRoot → V15 twice more; one earlier ChoralRoot → V15 ended with a pipe error, see below

One install through the hub, ChoralRoot → V15, ended with "Pipe error" at the very end, although the FM-1 had received V15 and was running it. It looks like the FM-1 flasher, not TinyUSB: after the last block the FM-1 restarts, the host sees the restart late through a hub, and the flasher's reply to a repeated "finish" request can go to a device that has gone. The flasher's console trace doesn't log that exchange, so this is the likely cause rather than a confirmed one. The flasher now ignores a failed reply at that point (adafruit/Adafruit_Learning_System_Guides#3330). Two repeats of the same install through the hub passed.

Board changes

atmegazero_esp32s2 and microdev_micro_s2 overflowed dram0_0_seg by 16 bytes with the new TinyUSB, so this turns audiopwmio off on those two boards.

On main they had 16 bytes free in that region, which holds static internal RAM plus the code that must run from internal RAM. The new TinyUSB adds 32 bytes of USB state there (_dcd_data, _usbh_data, _usbd_task_stop, plus alignment). audiopwmio's timer ISR, which has to be in IRAM (#11663), takes about 450 bytes of the same region, so with it off both boards link with 528 bytes free. Neither board has an onboard speaker. Other ESP32-S2 boards still have room, including the FeatherS2 with the same 16 MB flash and 8 MB PSRAM.

#11663 checked flash headroom but not this region. If you'd rather keep audiopwmio on these boards, a port-wide change to move some IRAM code to flash would also do it, but that seemed out of scope here.

Five nRF52840 boards (pca10059, makerdiary_nrf52840_mdk_usb_dongle, raytac_mdbt50q-db-40, ssci_isp1807_micro_board, teknikio_bluebird) overflow flash in ru only, by 60 to 324 bytes. #11830 turns off msgpack on nRF52840 boards with an internal flash filesystem (cb62fd7), which leaves these boards about 2.5 KB free in ru, so this PR should merge after #11830. I'll update the branch from main then.

Other TinyUSB changes users may notice

Change	Effect
hathach/tinyusb#4265	DWC2 host (ESP32-S2/S3/P4): split transactions through high-speed hubs are scheduled per transaction translator, and isochronous splits are supported.
hathach/tinyusb#4302, #4333, #4280, #4448, #4234, #3984	DWC2 device (ESP32-S2/S3/P4 USB serial and CIRCUITPY): full-speed on a high-speed PHY, EP0 status with DMA, IN endpoints beyond the TX FIFOs, TX FIFO writes across cores, RX FIFO fallback.
hathach/tinyusb#4068, #4211, #4281	nRF52 device: EP0 and OUT packet handling after a new SETUP or clear-halt, ISO OUT DMA bound.
hathach/tinyusb#4392	SAMD: a queued IN bank is cleared on stall.
hathach/tinyusb#4349	RP2040 device: deferred zero-length packet.
hathach/tinyusb#4303, #4432, #4344, #4005, #4230	USB host: configuration length check, a device removed during its mount callback, MIDI host read bound, HID host report on a failed transfer, MSC host max LUN.
The rest of the 107 merged PRs	CI, hardware-in-the-loop test rig and docs. No CircuitPython change needed.

Main only.

Hardware tested

Board	Test
Metro ESP32-P4	FM-1 firmware installs, directly and through a hub, on this exact build and on #4265's head. CIRCUITPY and USB serial in use throughout.
The eight boards below	Mikey's test farm (Ubuntu 24.04 host), this branch against its parent 1251392, only lib/tinyusb changed. Each round: the board writes 5 x 64 KB to USB serial, then a 64 KB file is written to CIRCUITPY, read on the board and read back on the host after a remount. Main and this branch alternated, 3 to 4 rounds each. No lost bytes and no drive errors on any board at either pin.

Board	main KB/s	this PR KB/s	flash cost
Metro M0 Express	306-365	342-366	108 B
Metro M4 AirLift Lite	521-524	521-524	76 B
Feather nRF52840 Express	295-303	293-299	400 B
Feather STM32F405 Express	534-538	529-538	488 B
Metro RP2040	375-395	389-395	1320 B
Metro RP2350	487-502	480-485	1296 B
Metro ESP32-S2	400-442	429-445	976 B
Metro ESP32-S3	366-376	364-373	1200 B

The ESP32-S2 is about 5% faster and the RP2350 about 2% slower, both in every round. Everything else is within noise. The throughput test differs from #11582's, so these numbers don't line up with that table.

The Metro ESP32-P4 costs 9744 B (macOS build, TRANSLATION=en_US), most of it the DWC2 host split scheduler. No new warnings.

Not tested: USB host on boards other than the Metro ESP32-P4, Windows hosts, and throughput on macOS hosts.

AI assistance

Claude Code made the change and ran the builds. I ran the FM-1 installs on the Metro, and @mikeysklar ran the board farm.

🤖 Generated with Claude Code

[dhalbert]

Brought up to date to include #11844, so should build successfully now