RP2040 HCD driver does not correctly recover from data sequence errors per USB Spec 8.6.4

[rppicomidi]

Operating System

Linux

Board

Raspberry Pi Pico

Firmware

usb_midi_host_example

What happened ?

This is with regards the RP2040 USB Host mode chip bug described here: raspberrypi/pico-feedback#394.

TinyUSB implements host mode bulk and interrupt endpoints using the automatically polled endpoint hardware on the RP2040. That hardware has a bug that prevents it from recovering from data sequence errors per the USB specification section 8.6.4. Normally, data sequence errors due the device missing ACK are rare unless the environment is noisy or the hardware is bad. However, there are commercial devices with at least one IN endpoint where the first Bulk IN or Interrupt IN transfer starts with DATA1 PID instead of DATA0. Either way, any data sequence error freezes up the host hardware for that endpoint in an infinite loop instead of replying ACK and discarding the data. The RP2040 has no way to detect this condition and recover from it.

The right thing to do is to rewrite the RP2040 HCD to use only EPx. At least that endpoint hardware has a way to detect data sequence errors and should actually implement USB specification 8.6.4 correctly. However, rewriting the HCD is a relatively long task. The new HCD has to route all Bulk IN and and Interrupt IN transfers through EPx to avoid the hardware bug. Once we are doing that, it seems that we should try to improve all Bulk and Interrupt transfer throughput by managing transfers in software.

For a quicker solution, I have a patch to TinyUSB that allows an application to tell the RP2040 HCD about specific device IN endpoints on devices with a given VID:PID that are known to always start the first Bulk IN or Interrupt IN transfer with DATA1 PID. The patch changes the expected first PID to DATA1 instead of DATA0 when the HCD opens the known faulty endpoint. This patch is known to work: See rppicomidi/usb_midi_host#14 near comments 40.

@hathach, if I submit this patch as a pull request, would you consider it, or is it too much of a hack? In my mind, it should be a temporary solution. It requires applications to have a list of commercial devices that are known to be buggy. The patch still does not allow the RP2040 USB Host mode to recover from a data sequence error due to noise. It is useful as a temporary fix until the HCD gets a rewrite, however.

How to reproduce ?

See the discussion here: https://github.com/raspberrypi/pico-feedback/

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

N/A

Screenshots

N/A

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[rppicomidi]

@hathach Really fixing this bug requires writing a new HCD for the RP2040 hardware that only uses epx hardware. These are my thoughts on the design. Do you have any comments or suggestions?

• The interrupt handler must schedule every pending transfer
• To do that, the interrupt handler must service SOF interrupts to properly allocate bandwidth per frame
• The interrupt handler must service NAK interrupts to know when to try a different pending transfer
• The HCD cannot rely on the automatic retry after NAK feature of the RP2040 hardware. However, the NAK_POLL feature cannot be disabled, even by setting NAK_POLL interval to 0 or to the maximum value (I tried both). Therefore, it must set NAK_POLL to the maximum value, which is 1023 microseconds, and the interrupt handler must abort the current transfer when it handles the NAK interrupt. It has about 1ms to handle the NAK interrupt and abort the pending transfer before the automatic retry mechanism will start another transfer.
• The interrupt handler scheduler will maintain a list of pending transfers. When the handler gets SOF or a NAK interrupt, it will attempt the next pending transfer. The scheduler will prioritize reserved bandwidth pending transfers (interrupt endpoints), then control transfers, then bulk. Support of isochronous transfers is a future feature.

This design will greatly increase interrupt frequency because it handles the SOF interrupt and will increase it more because it handles every NAK. Hopefully, the RP2040 can handle interrupts fast enough that this change will improve performance of bulk transfers.