commit | 3f40cf78e61215f8841877ab7327d06e47485e55 | [log] [tgz] |
---|---|---|
author | Piotr Koziar <44554861+piotrkoziar@users.noreply.github.com> | Thu Oct 14 07:05:37 2021 +0200 |
committer | GitHub <noreply@github.com> | Wed Oct 13 22:05:37 2021 -0700 |
tree | 9c08c19295868fa02be7c17ff187401862706c0c | |
parent | 7dd7a5d7d682505826031dca018560615e0a8789 [diff] |
[csl] prevent CslTxScheduler from entering the incorrect state (#7070) Problem: I have encountered CslTxScheduler entering the incorrect state causing the device to be unable to perform csl transmission. The state is when mCslTxChild is null but mCslTxMessage is not null. As a result Update() call does not have any effect. I think that we enter the incorrect state when the following happens: 1. CSL transmission on mac is requested (mCslTxChild is set to the best child found in RescheduleCslTx(), mCslTxMessage is set to the child's IndirectMessage in HandleFrameRequest()) 2. During the ongoing mac CSL transmission, Update() is called (this method can be called from multiple places) 3. The mCslTxChild's IndirectMessage differs from the mCslTxMessage ==> mCslTxChild is set to nullptr 4. After the finished csl transmission on mac, the HandleSentFrame() is called but it does not call RescheduleCslTx() so the mCslTxChild remains nullptr Then every Update() call does not have any effect. To change that we would have to call RescheduleCslTx() or set the mCslTxMessage to null but there is no way of doing that. Solution: I believe that mCslTxMessage is "tracking" the mac transmission - it is to be set when transmission is requested, and to be cleared when the transmission ends. In this commit we are doing it in a clear way.
OpenThread released by Google is...
...an open-source implementation of the Thread networking protocol. Google Nest has released OpenThread to make the technology used in Nest products more broadly available to developers to accelerate the development of products for the connected home.
...OS and platform agnostic, with a narrow platform abstraction layer and a small memory footprint, making it highly portable. It supports both system-on-chip (SoC) and network co-processor (NCP) designs.
...a Thread Certified Component, implementing all features defined in the Thread 1.1.1 specification, including all Thread networking layers (IPv6, 6LoWPAN, IEEE 802.15.4 with MAC security, Mesh Link Establishment, Mesh Routing) and device roles, as well as Border Router support.
More information about Thread can be found at threadgroup.org. Thread is a registered trademark of the Thread Group, Inc.
All end-user documentation and guides are located at openthread.io. If you're looking to do things like...
...then openthread.io is the place for you.
Note: For users in China, end-user documentation is available at openthread.google.cn.
If you're interested in contributing to OpenThread, read on.
We would love for you to contribute to OpenThread and help make it even better than it is today! See our Contributing Guidelines for more information.
Contributors are required to abide by our Code of Conduct and Coding Conventions and Style Guide.
OpenThread follows the Semantic Versioning guidelines for release cycle transparency and to maintain backwards compatibility. OpenThread's versioning is independent of the Thread protocol specification version but will clearly indicate which version of the specification it currently supports.
OpenThread is released under the BSD 3-Clause license. See the LICENSE
file for more information.
Please only use the OpenThread name and marks when accurately referencing this software distribution. Do not use the marks in a way that suggests you are endorsed by or otherwise affiliated with Nest, Google, or The Thread Group.
There are numerous avenues for OpenThread support:
openthread
tagThe openthread-users Google Group is the recommended place for users to discuss OpenThread and interact directly with the OpenThread team.