EP0 IN is armed at bus reset and never taken back

1What was measured

On the wire, after a bus reset, the host's first GET_DESCRIPTOR is answered twice:

• a DATA0 packet of 64 bytes, which the host ACKs and discards;
• then, on the retry, a DATA1 packet of 18 bytes — the correct device descriptor.

USB 2.0 §8.5.3 requires the first data packet of a control transfer's data stage to be DATA1, so a host is right to reject the first one. Some hosts tolerate the retry and enumerate anyway; others fail the address assignment outright, which is the Unknown USB Device (Set Address Failed) in the report. That difference is why this looks machine-dependent: a Windows laptop fails, a mini PC works, a Raspberry Pi 4 does it intermittently.

The two wrong values are worth reading together, because they have one cause. 64 and DATA0 are not what any code path computed for this descriptor. They are what handle_bus_reset put in the register, some microseconds earlier.

2Who owns the buffer

The RP2040's endpoint buffers are in a dual-port RAM that both the CPU and the USB controller can reach. The AVAILABLE bit is the handover: the CPU sets it to give the controller the buffer, and the controller clears it when it has used it. Step through what that bit does here.

3What bus reset writes

Three fields, one of which gives the buffer away:

The line has been there since the driver's first commit, 4d903e2c9 of 2022-11-02, and has never been modified. It is also inconsistent with the rest of the same function. handle_bus_reset writes exactly one other endpoint buffer — the bulk OUT one — and that write clears it to zero before it sets AVAILABLE. No other buffer is written at all: a control endpoint gets a state change and nothing else, and the bulk IN side is left alone.

chips/rp2040/src/usb.rs:1535 — the bulk OUT path, earlier in the same function
self.dpsram.ep_buf_ctrl[ep].ep_out_buf_ctrl.set(0);
self.dpsram.ep_buf_ctrl[ep].ep_out_buf_ctrl.modify(
    EP_BUFFER_CONTROL::AVAILABLE0::SET
        + EP_BUFFER_CONTROL::TRANSFER_LENGTH0.val(64_u32),
);

chips/rp2040/src/usb.rs:1552 — EP0 IN, with no clear
self.dpsram.ep_buf_ctrl[0].ep_in_buf_ctrl.modify(
    EP_BUFFER_CONTROL::AVAILABLE0::SET
        + EP_BUFFER_CONTROL::TRANSFER_LENGTH0.val(64)
        + EP_BUFFER_CONTROL::DATA_PID0::CLEAR,
);

4The analysis in the issue, checked

The report includes an AI-generated analysis. Two of its three claims hold up and the third does not, which matters because the third is the one that implies a patch.

chips/rp2040/src/usb.rs:2096 — transmit_in_ep0, the ordering is already right
if self.next_pid_in[endpoint].get() == 1 {
    self.dpsram.ep_buf_ctrl[endpoint].ep_in_buf_ctrl.modify(
        EP_BUFFER_CONTROL::TRANSFER_LENGTH0.val(size as u32)
            + EP_BUFFER_CONTROL::BUFFER0_FULL::SET
            + EP_BUFFER_CONTROL::DATA_PID0::SET,
    );
    self.next_pid_in[endpoint].set(0);
} /* ... */
self.nop_wait();
self.dpsram.ep_buf_ctrl[endpoint]
    .ep_in_buf_ctrl
    .modify(EP_BUFFER_CONTROL::AVAILABLE0::SET);

The report also asks why the device sends 64 bytes where the descriptor is 18. Same cause: 64 is the stale TRANSFER_LENGTH0 from the reset, not a length any descriptor path computed. The reference driver sends MIN(sizeof(descriptor), wLength).

5What the datasheet requires

The AVAILABLE bit in the buffer control register is used to indicate who has ownership of a buffer. This bit should be set to 1 by the processor to give the controller ownership of the buffer. The controller will set the bit back to 0 when it has used the buffer.

RP2040 datasheet, §4.1.2.7.1, Concurrent access

The [USB specification] states that receiving a setup packet also clears any stall bits on EP0. For this reason, the stall bits for EP0 are gated with two bits in the EP_STALL_ARM register. These bits are cleared when a setup packet is received.

RP2040 datasheet, §4.1.2.8.1, SETUP

The second quote is the one that closes the argument. The section describing what a SETUP packet does to the device controller lists the stall bits, the setup buffer at DPSRAM offset 0, and SIE_STATUS.SETUP_REC. There is no mention of buffer-control ownership, so the buffer armed at bus reset is still armed when the request arrives.

6What the reference driver does instead

Worth stating as a measurement rather than an impression. In the whole of dev_lowlevel.c, 582 lines:

• there is exactly one write to a buffer control register, at line 259, and it is a single 32-bit store of a value built from scratch: *ep->buffer_control = val;
• USB_BUF_CTRL_AVAIL appears exactly once, at line 246, where that value is assembled;
• usb_bus_reset, line 314, sets the device address to zero and clears two flags. It touches no endpoint buffer at all.

So the reference never has a buffer that is available without holding the data it is meant to send, and never read-modify-writes one. Tock does both, on EP0 IN, from reset until the first descriptor goes out.

7The change

The minimal fix is to stop giving the buffer away. There is nothing to send at bus reset, and the endpoint NAKing until there is, is the correct behaviour:

chips/rp2040/src/usb.rs:1552
-self.dpsram.ep_buf_ctrl[0].ep_in_buf_ctrl.modify(
-    EP_BUFFER_CONTROL::AVAILABLE0::SET
-        + EP_BUFFER_CONTROL::TRANSFER_LENGTH0.val(64)
-        + EP_BUFFER_CONTROL::DATA_PID0::CLEAR,
-);
+// Leave EP0 IN unarmed. There is nothing to send until a SETUP
+// arrives, and an available buffer is one the controller owns --
+// transmit_in_ep0() would then be rewriting its length and PID
+// underneath it.
+self.dpsram.ep_buf_ctrl[0].ep_in_buf_ctrl.set(0);

A second, larger change is worth considering separately: making transmit_in_ep0 build the buffer control value and write() it, rather than modify() it. Every modify() on these registers is a read of a register the controller also writes status into. Clearing AVAILABLE at reset removes the window that this bug goes through; it does not make the read-modify-write pattern correct in general.

8What this does not establish

• The fix is not tested. I do not have an RP2040 board. Everything above is read from the source, the datasheet and the reference driver, plus the capture in the report. Nobody should merge the diff in section 7 on the strength of this page — it needs someone with a Pico, an analyser and the failing host.
• The RP2350 cannot stand in for it. chips/rp2350 has no USB driver at all; the only usb matches on a Pico 2 board are PllUsb clock names. Only the four RP2040 boards have USB at all, and only three of them name it: raspberry_pi_pico, pico_explorer_base and nano_rp2040_connect instantiate rp2040::usb::UsbCtrl, while raspberry_pi_pico_w inherits it as a binary over raspberry_pi_pico::Platform.
• The race is inferred, not observed. That the controller samples the buffer control before transmit_in_ep0 rewrites it is what the capture is consistent with and what the ownership rule predicts. I have not instrumented it.
• It may not be the only cause. The capture shows one defect clearly. Whether fixing it is sufficient for the Dell and HP hosts in the report is an open question, not something this page answers.
• One loose end, unrelated. boards/raspberry_pi_pico/src/lib.rs passes a literal 64 as the CDC control packet size with MAX_CTRL_PACKET_SIZE_RP2040 commented out beside it — and that constant does not exist in capsules/extra/src/usb/cdc.rs, which defines only the SAM4L, nRF52840 and EarlGrey ones. The literal is a valid value; the commented name is dead.