@andrewleech FYI

Code size report:

Reference:  esp8266: Remove obsolete --verify option from ESP8266. [e496000]
Comparison: stm32/tinyusb_port: Add missing USB_HS_PHYC_PLL1_PLLSEL constants. [merge of 690dcbf]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Oh whoops - is this different to the PYBD_SF6 ? I did test on that on earlier version of my PR.

The SF3 has built-in USB HS PHY, whereas the SF2/SF6 require an external HS PHY (and so use USB HS in FS mode).

Ah right, that makes sense. To check for similar issues I did a build of all 79 stm32 boards without TinyUSB and again clean with CFLAGS_EXTRA=-DMICROPY_HW_TINYUSB_STACK=1. All 79 pass without TinyUSB. With it forced on, 70/79 pass - the 9 failures all look pre-existing:

PYBD_SF3 passes the no-TinyUSB build so the fix works. The tusb_time_millis_api failure is because SF3 is the only board with USB_HS_PHYC that gets far enough to link - the PHYC init in dwc2_stm32.h calls tusb_time_delay_ms_api which pulls in the unresolved extern. Fix would be adding to shared/tinyusb/mp_usbd.c:

+uint32_t tusb_time_millis_api(void) {
+    return mp_hal_ticks_ms();
+}
+
 #endif // MICROPY_HW_ENABLE_USBDEV

Thanks for testing the build.

It looks like tusb_time_delay_ms_api() is the function needed by TinyUSB. Implementing only tusb_time_millis_api() would lead to the default implementation of tusb_time_delay_ms_api() which is a busy loop. And I'd rather not waste power for 2ms if it can be avoided. So I think it's better to implement tusb_time_delay_ms_api() directly, eg on stm32 using HAL_Delay(ms).

Raised #19213 for the tusb_time_delay_ms_api fix.