samd: USB interface locks up when input symbols arrive too fast.

[robert-hh]

There is a USB interface issue, that the USB interface locks up if input symbols arrive too fast AND are echoed back. In the master branch, this is hard to replicate. The Issue got evident with #8520, where the issues can re reproduced easily.
When the USB interface seems to be locked up, the board continues to work. Analysis in the Debugger shows, that input symbols still arrive and are processed. Output to commands will be created and the function mp_hal_stdout_tx_strn() is called, which in turn calls tud_cdc_write() and tud_cdc_write_flush(). Only the data does not arrive at the connected PC/USB interface.

[robert-hh]

While the USB interface seems to be locked, REPL output still goes to UART for a while, but locks up later as well, probably because the USB output buffer is filled up.
When REPL input from UART is used, all works well. No lock-up. But maybe only because the symbol input rate is limited by the baud rate.

[robert-hh]

It looks like I found the culprit in the tinyusb lib. Making the change below the error is gone. It's the right spot for causing the issue. Now I have to make a PR and convince @hathach to change it, and then make the matching PR for the MicroPython repository.

diff --git a/src/portable/microchip/samd/dcd_samd.c b/src/portable/microchip/samd/dcd_samd.c
index 526a6fb63..68aa5ab75 100644
--- a/src/portable/microchip/samd/dcd_samd.c
+++ b/src/portable/microchip/samd/dcd_samd.c
@@ -271,14 +271,14 @@ bool dcd_edpt_xfer (uint8_t rhport, uint8_t ep_addr, uint8_t * buffer, uint16_t
   {
     bank->PCKSIZE.bit.MULTI_PACKET_SIZE = total_bytes;
     bank->PCKSIZE.bit.BYTE_COUNT = 0;
-    ep->EPSTATUSCLR.reg |= USB_DEVICE_EPSTATUSCLR_BK0RDY;
-    ep->EPINTFLAG.reg |= USB_DEVICE_EPINTFLAG_TRFAIL0;
+    ep->EPSTATUSCLR.reg = USB_DEVICE_EPSTATUSCLR_BK0RDY;
+    ep->EPINTFLAG.reg = USB_DEVICE_EPINTFLAG_TRFAIL0;
   } else
   {
     bank->PCKSIZE.bit.MULTI_PACKET_SIZE = 0;
     bank->PCKSIZE.bit.BYTE_COUNT = total_bytes;
-    ep->EPSTATUSSET.reg |= USB_DEVICE_EPSTATUSSET_BK1RDY;
-    ep->EPINTFLAG.reg |= USB_DEVICE_EPINTFLAG_TRFAIL1;
+    ep->EPSTATUSSET.reg = USB_DEVICE_EPSTATUSSET_BK1RDY;
+    ep->EPINTFLAG.reg = USB_DEVICE_EPINTFLAG_TRFAIL1;
   }
 
   return true;

P.S.: I did not search for it all the time. Just here and then.

[dpgeorge]

Great work! Let's hope it gets fixed in upstream TinyUSB soon.

[robert-hh]

Thanks. I made a PR, but for the current master branch. The SAMD port works with that branch. So either we could work with different commits for the various ports, or we switch them all.

[dpgeorge]

It's too difficult to use different TinyUSB commits for different ports... would be best to wait for the next release of TinyUSB.

[robert-hh]

There is already a new TinyUSB version. MicroPython uses version 0.12.0. The master branch is beyond the version 0.13.0 tag. And the RP2 branch does not build with that version. Two errors:

a) an undefined C Macro: PICO_SHARED_IRQ_HANDLER_HIGHEST_ORDER_PRIORITY
b) a missing function: undefined reference to "tud_task"

So using a new TinyUSB version requires rework of some ports.

[robert-hh]

Adaption for rp2 should be easy. a) is just a different #define, which is already present in newer version for the pico lib.
b) tud_task() is now tud_task_ext() with two arguments, of which one is not used. So either a wrapper or a redefine will do.

[robert-hh]

So the change is already merged with the master branch of tinyusb. I asked also Ha Thach to have a v0.12.0 branch for a while fro MicroPython, but he is reluctant to do so; understandable. I use a local copy of that changed file at the moment, because I did not expect such a fast response. And I can take care of checking the mimxrt and rp2 branch for an updated tinyusb version. But there are ESP32, nrf and STM32(?) which use that as well. I have no NRF boards for testing, and just one ESP-Cx variant. Of course I can try the updated lib with these. So it's some work to do.

[dpgeorge]

ESP32 uses it's own version of TinyUSB in the IDF, so no need to worry about that.

There are no stm32 boards using TinyUSB.

I have nRF boards that I can test.

[robert-hh]

Thanks. Ha Thach mentioned that he will publish a release (v1.x?) of TinyUSB in the next days.

[robert-hh]

Fixed with the tinyusb update.