PIO USB Host Example programs can crash on device unplug

[rppicomidi]

For the EZ_USB_MIDI_HOST_PIO_example programs, both C++ and Arduino, the example programs will lock up most of the time on USB device unplug when used with a powered hub. The code seems to crash in the Pico PIO USB library. The issue needs investigation, but the behavior make is seem that the hub does not notice the device has been unplugged.

I do not observe the same issue with the same Pico W and USB hub hardware with the pico-usb-host-msc-demo project. Perhaps there is a bug in the usb_midi_host driver.

[fikryfadh]

@rppicomidi When i connect midi device (multifx) directly into port it has no issue, but when using hub it has problem when disconnect or remove from hub port, so i trying with flashdisk since i dont have another midi device, and it works for detect plug and removed it in hub port, maybe it because flashdisk msc and not being enumerate by midih_open?

my case when using hub its need to remove entire hub to stop midi device crashing, maybe the problem is hub_addr and hub_port not being configured for tracking? adding hub configuration for enumeration tuh_midi_mount_cb maybe its help for clean up midih_close / tuh_midi_umount_cb later for detect spesific midi device removed from hub port.

by the way pio_usb_host_add_port can be used to add another physical usb host, the behavior its start indexing by 1 from any port, it my recent option for connecting 2 device without hub.

[rppicomidi]

@fikryfadh I believe I have figured out what is going wrong with MIDI that does not happen with MSC. MIDI continuously polls the IN endpoint. The MSC driver does not. During unplug, I observe the IN endpoint transfer poll failing (which it should; the device is not there), and then the hub event transfer fails. The hub event interrupt endpoint needs to send back the unplug event successfully or the hub driver won't be able to detect the unplug event. It is not clear why the hub transfer fails.

I should have mentioned that I am doing my testing with the usb_midi_host driver directly; so the lower layer driver fails before this one gets a chance to.

[rppicomidi]

It is not clear to me why the hub IN transfer immediately after the failed transfer from the unplugged device also fails. However, the following work-around (patch to TinyUSB) makes the problem go away on my system. Consider this a hack for now. I will file an issue on the TinyUSB website.

diff --git a/src/host/hub.c b/src/host/hub.c
index e97014443..daf036d60 100644
--- a/src/host/hub.c
+++ b/src/host/hub.c
@@ -334,7 +334,18 @@ static void connection_port_reset_complete (tuh_xfer_t* xfer);
 bool hub_xfer_cb(uint8_t dev_addr, uint8_t ep_addr, xfer_result_t result, uint32_t xferred_bytes) {
   (void) xferred_bytes; // TODO can be more than 1 for hub with lots of ports
   (void) ep_addr;
+
+  static uint8_t retries = 0;
+  if (result == XFER_RESULT_FAILED) {
+    // try again up to 3 times.
+    if (retries++ < 3) {
+      hub_edpt_status_xfer(dev_addr);
+      TU_LOG2("HUB Xfer failed; retry %u\r\n", retries);
+    }
+    return 0;
+  }
   TU_VERIFY(result == XFER_RESULT_SUCCESS);
+  retries = 0;
 
   hub_interface_t* p_hub = get_itf(dev_addr);

[rppicomidi]

The previous fix is not reliable. Needs more investigation.

[rppicomidi]

I pushed a fix to the usb_midi_host driver. Now the fix is reliable. I have filed issue hathach/tinyusb#2971 to the TinyUSB project.