Can the RP2040 USB host adapt to a device that replies to the first BULK IN transfer with a DATA1 PID packet? #2702
-
|
This question concerns a device that cannot properly communicate via the usb_midi_host application USB Host driver for the RP2040. The issue, along with many USB packet sniffer traces, is tracked here. The summary is that after successful device enumeration, the usb_midi_host driver starts a Bulk IN transfer on endpoint 1. The first non-NAK transfer from the device has a DATA1 PID. It is my understanding that the first DATAx PID after SET CONFIGURATION should be DATA0. The RP2040's USB engine seems to agree, and per the USB spec, does not respond to the transfer. However, the device does not adapt. Instead, it sends the same packet with the same DATA1 PID in response to every subsequent IN request from the host. This device works fine with a Mac. USB traces show the Mac re-synchronizes the DATAx toggle to the device and sends ACK for every data packet, including the first one that starts with a DATA1 PID. The application driver has no control of USB at this level. After digging in the current HCD source, I have been unable to find a way to convince the RP2040 USB engine to work with this ill-behaved device. Is there a way to do it? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
According to the USB 2.0 specification 8.6.4, the USB Host is supposed to send ACK to the USB Device and ignore the data payload from the Device if the Device sends a packet with a DATA1 PID when the USB Host expects a DATA0 PID. That the USB packet sniffer traces contained in this issue show the RP2040 USB Host hardware does not do that indicate there is probably an undocumented chip erratum in the RP2040's USB Host hardware. |
Beta Was this translation helpful? Give feedback.
-
|
This appears to be a RP2040 chip issue. See raspberrypi/pico-feedback#394 |
Beta Was this translation helpful? Give feedback.
-
|
The answer is yes, sort of. You can control the initial value of the DATA0/DATA1 PID for each endpoint in the buffer control register for that endpoint, bit 13. See section 4.1.2.5.4. Buffer control register in the RP2040 specification document. There is a chip bug in the auto-sequenced host hardware, so the adaptation is not automatic and there is no register to allow software to detect that this issue occurring for a random device. The workaround is to know in advance that a particular device has an issue, and then program the buffer control register bit for the misbehaving endpoint opposite what it should normally be. The real workaround for this issue is to not use EP1-EP15 auto-sequenced interrupt host endpoints at all and do all host transfers through the single EPx endpoint register set. |
Beta Was this translation helpful? Give feedback.
The answer is yes, sort of. You can control the initial value of the DATA0/DATA1 PID for each endpoint in the buffer control register for that endpoint, bit 13. See section 4.1.2.5.4. Buffer control register in the RP2040 specification document. There is a chip bug in the auto-sequenced host hardware, so the adaptation is not automatic and there is no register to allow software to detect that this issue occurring for a random device. The workaround is to know in advance that a particular device has an issue, and then program the buffer control register bit for the misbehaving endpoint opposite what it should normally be.
The real workaround for this issue is to not use EP1-EP15 auto-seque…