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> |
||
|---|---|---|
| .github | ||
| arch | ||
| audio | ||
| binfmt | ||
| boards | ||
| cmake | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| dummy | ||
| fs | ||
| graphics | ||
| include | ||
| libs | ||
| mm | ||
| net | ||
| openamp | ||
| pass1 | ||
| sched | ||
| syscall | ||
| tools | ||
| video | ||
| wireless | ||
| .asf.yaml | ||
| .codespell-ignore-lines | ||
| .codespellrc | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmessage | ||
| .pre-commit-config.yaml | ||
| .yamllint | ||
| AUTHORS | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| INVIOLABLES.md | ||
| Kconfig | ||
| LICENSE | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| ReleaseNotes | ||
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOSs (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
Getting Started
First time on NuttX? Read the Getting Started guide! If you don't have a board available, NuttX has its own simulator that you can run on terminal.
Documentation
You can find the current NuttX documentation on the Documentation Page.
Alternatively, you can build the documentation yourself by following the Documentation Build Instructions.
The old NuttX documentation is still available in the Apache wiki.
Supported Boards
NuttX supports a wide variety of platforms. See the full list on the Supported Platforms page.
Contributing
If you wish to contribute to the NuttX project, read the Contributing guidelines for information on Git usage, coding standard, workflow and the NuttX principles.
License
The code in this repository is under either the Apache 2 license, or a license compatible with the Apache 2 license. See the License Page for more information.