Update TinyUSB submodule commit

[samblenny]

This is the latest upstream TinyUSB commit. There were many changes in the past 3 months since the last submodule update. In particular, there were some fixes for descriptor parsing and better stability when devices are unplugged. See issue #10556.

Checks:

• pre-commit passed (all checks were skipped because only submodule commit was changed)
• Build with make -j BOARD=adafruit_fruit_jam worked fine
• Firmware build seemed to work fine on Fruit Jam rev D with a couple of my USB Host MIDI projects

As Dan mentioned in the related issue, this will need more testing for other boards.

[samblenny]

Looks like some of the CI builds are failing (feather_m0_express, etc), but it's not evident to me why from looking at the action runner log. By my reading, it seems like the .uf2 files are actually getting created successfully, but then something else is going wrong?

[dhalbert]

@samblenny Some of the larger language builds in particular boards are too big, For instance, de_DE for feather_m0_express is too big by 12 bytes. By comparison, the most recent PR merge (#10550) of that build had 236 bytes of room remaining.

I will look for some modules that we might turn off. For instance, on feather_m0_express, codeop, maybe fontio, and/oor maybe one of the displayio bus support modules could be turned off. I'll look at this more later. But you could go ahead and test with the artifacts that did build. The en_US build fits, for instance.

[samblenny]

What did you have in mind for testing? I tried some casual stuff with code from my recent projects on a Fruit Jam board, and it seemed fine. My board collection is pretty small--mostly just RP2350, ESP32-S3, RP2040, and a little nRF52840. I have a couple SAMD21 boards, but those don't include any of the ones where the builds failed.

[dhalbert]

@tannewt On these M0 Express boards that are overflowing, we enable epaperdisplay, fourwire, i2cdisplaybus, and paralleldisplaybus. Are there any of these that you would say are impractical on a SAMD21 due to memory requirements or even pin requirements? fourwire and i2cdisplaybus I'd assume we'd keep, but I'm not sure about the others.

[dhalbert]

What did you have in mind for testing?

I am thinking specifically of the USB issues that you mentioned. If it fixes those, it would be great to close them. I am not thinking we'd have to do a lot of regression testing. USB Host should be tested, of course.

[samblenny]

I am thinking specifically of the USB issues that you mentioned.

oh... that would be kind of a major research project. I'm planning to do that work, but I expect it will take a while. As it stands, I don't have good reproducers for most of the stuff I mentioned in those other "USB Host: *" issues. I've just adopted workarounds to dodge around weirdness that I stumbled on last year when I was starting all the USB host gamepad stuff.

[dhalbert]

We often update TinyUSB without comprehensive testing. I was just hoping you could check off some known issues, like the plug/unplug one, etc.

[samblenny]

known issues, like the plug/unplug one, etc.

For that one, there are two different things going on. My unplug issue is about ambiguity in USBTimeoutError exceptions because Circuitpython doesn't set usb.core.USBTimeoutError.errno. The TinyUSB fix is about the potential for crashing or undefined behavior that could happen for an unplug during an in-progress transfer.

[samblenny]

I tested my firmware build for this PR to see if it helps with USB Host: Fast polling + write to CIRCUITPY crashes board #10562, but it doesn't seem to make any difference.

[samblenny]

I tested my firmware build for this PR to see if it helps with USB Host: Unplugging device can break usb.core.find() #10563, but it doesn't seem to make any difference.