Best way to deal with missing features in function tuh_control_xfer()

[Eqqm4n]

Hello-
Our project is quite often getting stuck infinitely in function tuh_control_xfer() from usbh.c, in particular this loop-

    while (result == XFER_RESULT_INVALID) {
      // Note: this can be called within an callback ie. part of tuh_task()
      // therefore event with RTOS tuh_task() still need to be invoked
      if (tuh_task_event_ready()) {
        tuh_task();
      }
      // TODO probably some timeout to prevent hanged
    }

And the top of the function includes this-

// TODO timeout_ms is not supported yet

It's easy enough to understand why we're in this loop. Our project does not use an RTOS and interrupts are not enabled, so we have to poll the MAX3421 INT line (our host controller of choice) to add events to the queue-

    do {
        result = OS_IsPinPortActive(&max3421_INT);
        if (result.value.v_tBool == O$_FALSE) {
            _tuh_int_hanlder_2arg(BOARD_TUH_RHPORT, false); // note the misspelling of 'handler'
        } // end if
        tuh_task();
        cdc_app_task();
    } while (O$_TRUE);

So it's easy enough to add this same polling to the while-loop we're getting stuck in. The bigger concern is how to properly exit if we implement the timeout ourselves. If we're stuck in that loop and time expires, what should happen exactly? The function exits or something else?

[IngHK]

Good morning,
TinyUSB programs the MAX3421E to generate edge and not level triggered interrupts.
The MAX3421E generates INT pulses of only 10.6 us.

When polling the INT line it could be quite difficult to detect the pulse.
It is currently not possible to change this MAX3421 INT mode to level trigger via configuration, for example in tusb_config.h.
You can change it for yourself directly in the code of \src\portable\analog\max3421\hcd_max3421.c.
The INTLEVEL bit in the PINCTL register must be set in hcd_init(), lines 449-450:

  // full duplex, interrupt negative edge
  reg_write(rhport, PINCTL_ADDR, PINCTL_FDUPSPI, false);

By the way, the int handler should actually be called via tuh_int_handler(BOARD_TUH_RHPORT, false);

[IngHK]

Maybe it could still work the way you do it because the pulse is only used to retrigger the interrupt handler. From the MCU's perspective it would look like level triggered

[Eqqm4n]

Thank you for the feedback. We hadn't even looked at the fact that the MAX is pulsing IRQs, which seems like an odd HW design choice. Our code has been updated to use an enabled IRQ for the INT line coming from the MAX. With this we have seen some noticeable improvement in performance although the stack still is not working correctly with a hub.