Fix rx_when_idle never being propagated to radio config#3
Closed
Copilot wants to merge 7 commits intofor-reviewfrom
Closed
Fix rx_when_idle never being propagated to radio config#3Copilot wants to merge 7 commits intofor-reviewfrom
Copilot wants to merge 7 commits intofor-reviewfrom
Conversation
…correct alarm wrapping Process tasklets immediately after otPlatRadioReceiveDone, otPlatRadioTxDone, and otPlatAlarmMilliFired to match the standard OpenThread event loop pattern. This ensures deferred radio commands (e.g. from MeshForwarder tasklets) are processed before the radio loop starts its next operation, reducing gaps where the radio is idle and fragments can be missed. Also fix the alarm time computation to correctly handle u32 wrapping by computing the offset from current time in 32-bit wrapping space, rather than naively converting the truncated u32 back to a 64-bit Instant. Co-authored-by: ivmarkov <2607589+ivmarkov@users.noreply.github.com>
…sing Co-authored-by: ivmarkov <2607589+ivmarkov@users.noreply.github.com>
…bility Fix OpenThread stability: inline tasklet processing after events and correct alarm wrapping
- Add otPlatRadioSetRxOnWhenIdle callback in platform.rs for OpenThread C library builds that call it (e.g. when OT_RADIO_CAPS_RX_ON_WHEN_IDLE is supported) - Query link mode in plat_changed callback and sync rx_when_idle to radio_conf, ensuring the radio hardware is told to stay in receive mode when the Thread link mode requires it - Add plat_radio_set_rx_on_when_idle method in OtContext Previously, radio_conf.rx_when_idle was initialized to false and never updated, causing the ESP radio hardware to not stay in receive mode during idle periods. This led to missed 802.15.4 fragments and reassembly-timeout errors. Co-authored-by: ivmarkov <2607589+ivmarkov@users.noreply.github.com>
Co-authored-by: ivmarkov <2607589+ivmarkov@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Investigate rx_when_idle configuration in openthread
Fix rx_when_idle never being propagated to radio config
Feb 10, 2026
ivmarkov
force-pushed
the
for-review
branch
10 times, most recently
from
18574c6 to
3bca3bd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
radio_conf.rx_when_idleis initialized tofalseand never updated. The ESP radio hardware is never told to keep its receiver on during idle, causing missed 802.15.4 fragments and reassembly-timeout errors.Two issues compound here:
otPlatRadioSetRxOnWhenIdlewas not implementedotPlatRadioSetRxOnWhenIdle(symbol is unreferenced in all shipped.afiles), so implementing it alone is insufficientChanges
platform.rs: AddotPlatRadioSetRxOnWhenIdleextern callback — covers from-source builds where OT calls thislib.rs: QueryotThreadGetLinkMode().mRxOnWhenIdle()inplat_changedand sync toradio_conf— covers precompiled MTD libraries that fire state change callbacks but never callotPlatRadioSetRxOnWhenIdleupdate_rx_when_idlehelper to deduplicate the two update pathsFlow after fix
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.