Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (c9af4e1) to head (207562d).
⚠️ Report is 3 commits behind head on master.

@@           Coverage Diff           @@
##           master   #18406   +/-   ##
=======================================
  Coverage   98.38%   98.38%           
=======================================
  Files         171      171           
  Lines       22299    22299           
=======================================
  Hits        21938    21938           
  Misses        361      361           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

Reference:  tools/mpy-tool.py: Add Compiler Explorer JSON output. [c9af4e1]
Comparison: shared/tinyusb: Remove macro guard for tx_overwritabe_if_not_connected. [merge of 207562d]
  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
     mimxrt:  +376 +0.100% TEENSY40[incl +4(data)]
        rp2:  +380 +0.041% RPI_PICO_W[incl +8(bss)]
       samd:  +368 +0.135% ADAFRUIT_ITSYBITSY_M4_EXPRESS[incl +4(data) -4(bss)]
  qemu rv32:    +0 +0.000% VIRT_RV32

I've tested this with AE3 and N6 (my DFU bootloader, not the new stm32 stack support), and DFU and CDC seem to work fine.

One thing to note is that this update will bring in the header change from 3ec2e36 - as we now expect this to be enabled universally then we could take out the #if guard around it.

Good catch! I've now removed that header guard, and updated the struct name to the newer version.

I updated this PR to use the freshly released TinyUSB 0.20.0. Still needs testing.

I tested TinyUSB 0.20.0 on ADAFRUIT_ITSYBITSY_M0_EXPRESS (samd21) and there is a problem, it takes about 5 seconds between the USB device enumeration and the CDC to appear, and then some of the TX date appears in the RX buffer.

Doing a git bisect on TinyUSB, the commit that introduces that problem is: hathach/tinyusb@f11adb0

I spent a bit of time trying to work out the issue but did not make any progress (the issue could very well be with our integration of TinyUSB, although the bug doesn't happen on other ports). So for now I think we need to stick with 0.19.0-24, as originally tested for this PR.

@hathach FYI see above, it looks like there's a problem with TinyUSB 0.20.0 on samd21, at least with the way we are using it.

Are you testing with stock example like cdc_dual_ports ? Sounds like memory corruption that multiple buffers are overlapped.

@dpgeorge commit migrate cdc device to use common edpt stream API. maybe I miss something and/or there is some configure that need some tweak up. I will try to test when possible.

Are you testing with stock example like cdc_dual_ports ?

No, I'm was only testing with MicroPython, with all commits as at this PR.

But, I did now test the TinyUSB cdc_dual_ports example with the itsybitsy_m0 board profile, and the example works fine, the USB CDC appears immediately after enumeration.

I tested TinyUSB 0.20.0 on ADAFRUIT_ITSYBITSY_M0_EXPRESS (samd21) and there is a problem, it takes about 5 seconds between the USB device enumeration and the CDC to appear, and then some of the TX date appears in the RX buffer.

I had a similar experience with SAMD devices and previous TinyUSB versions, both the initial delay and output data appearing in the RX buffer. About the latter I had a discussion with @projectgus, but I did not find the link instantly. He said it was changed, but it still happens with various boards, both SAMD and ESP32. The initial delayed enumeration disappeared after I changed the USB hub on my desk. But that may have been just coincidence, because the change was for a different reason.

The initial delayed enumeration disappeared after I changed the USB hub on my desk

FWIW, I'm using a USB port directly into the (Arch Linux) PC, so the only USB hubs are the internal ones.

And my testing shows that the issue is clearly introduced by the TinyUSB commit I link to above.

I've rolled this back to just update TinyUSB to 0.19.0-24. That seems the safest option for the next MicroPython release.

Can work out what the issue is with TinyUSB 0.20.0 at a later date (and it could well be just a MicroPython integration issue, not a problem with TinyUSB itself).

@dpgeorge FYI the ARDUINO_NANO_33_BLE_SENSE REV2 gets stuck in a boot loop after this update I think.

Never mind, I can't get the board to work with any old release, it's probably broken.

I tested ARDUINO_NANO_33_BLE_SENSE REV2 again with latest master and it works OK.

I tested ARDUINO_NANO_33_BLE_SENSE REV2 again with latest master and it works OK.

Thanks! This confirms that my board is broken.