mirror of
https://github.com/apache/nuttx.git
synced 2026-10-18 11:39:00 +00:00
128ee6087f
rp2040_txcomplete() and rp2040_rxcomplete() unconditionally called rp2040_wrrequest()/rp2040_rdrequest() to start the next transfer after invoking a request's completion callback. When that callback resubmits a request on the same, now-idle endpoint -- which cdcncm and rndis do from their interrupt/notify completion handlers -- rp2040_epsubmit() already arms the hardware buffer for it. The unconditional re-arm in the completion path then arms the same buffer a second time, toggling the DATA0/DATA1 PID twice. The host sees a stale PID and silently discards the packet as a retransmission, so e.g. the cdcncm NETWORK_CONNECTION / SPEED_CHANGE notifications never reach the host and the interface stays NO-CARRIER. Track whether a request's hardware buffer has already been armed with a per-request flag (set in rp2040_wrrequest/rp2040_rdrequest, cleared in rp2040_epsubmit) and skip the redundant re-arm when the completion callback has already resubmitted. The in-progress multi-packet case (transfer not yet complete) still continues normally. Validated on raspberrypi-pico (RP2040): the cdcncm interrupt-IN notification is now delivered (confirmed with usbmon) and the host brings the link up; previously it never was. This is also the likely cause of the long-standing rndis control-response timeout on this controller. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AHJRvWeBMTHwzpwjaUg4HW Signed-off-by: Ricard Rosson <ricard@groundbits.com> |
||
|---|---|---|
| .. | ||
| include | ||
| src | ||
| CMakeLists.txt | ||
| Kconfig | ||