mpsl: clock_ctrl: Fix wait for LFCLK if timeout returned earlier #20782
Conversation
This file contains 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
github-actions
bot
added
the
changelog-entry-required
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 502d45d39682d214fb671be61c0c857a82958993 more detailssdk-nrf:
Github labels
List of changed files detected by CI (2)Outputs:ToolchainVersion: acee3b0b2b Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
|
You can find the documentation preview for this PR here. |
ppryga-nordic
force-pushed
the
mpsl-fix-double-wait-for-lfclk-if-timedout
branch
4 times, most recently
from
a38404e to
09a3f44
Compare
nordicjm
approved these changes
Mar 7, 2025
AyturkDuzen
requested changes
Mar 10, 2025
There is a workaround implemented in the MPSL clock control integration layer for cases where nrf2 clock control doesn't get response from sysctrl for the LFCLK request. The workaround was incorrectly implemented. After clock driver returned -NRF_ETIMEDOUT new call to m_lfclk_wait() was done. The new call waits on a semaphore that also returns timeout error. The second m_lfclk_wait() call returns -NRF_EFAULT error code that causes an assert in later stage of initialization. The change done is to make sure if a clock driver returns -NRF_ETIMEDOUT error for m_lfclk_wait then next m_lfclk_wait call immediately returns 0 (as if the clock was ready). That is based on an assumption: - the sysctrl implicitly provides a LFCLK with accuracy that is the same or better than requested by MPSL, - there are not other LFLCK requests from Radio core FW - if there is another LFCLK request put, it is for a LFCLK with accuracy the same or better than required by radio protocols. The change also affects LFCLK request and response APIs, so that the new requests or released for the clock will return immediately until the mpsl_clock_ctrl_uninit() is executed, that resets the sate of the m_lflclk_req_timeout flag. There is added a KConfig option: CONFIG_MPSL_EXT_CLK_CTRL_LFCLK_REQ- _TIMEOUT_ALLOW that can be used to disable the workaround. Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
ppryga-nordic
force-pushed
the
mpsl-fix-double-wait-for-lfclk-if-timedout
branch
from
09a3f44 to
502d45d
Compare
|
AyturkDuzen
approved these changes
Mar 11, 2025
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.
There is a workaround implemented in the MPSL clock control integration layer for cases where nrf2 clock control desn't get response from sysctrl for the LFCLK request,
The workaround was incorreclty implemented, so that after a -NRF_ETIMEDOUT was returned by clock driver another call to m_lfclk_wait attempte to wait and timedout on a semaphore. The second call with semaphore timeout returned -NRF_EFAULT error code that caused an assert in later initialization stage.
The change makes sure if a clock driver returns -NRF_ETIMEDOUT error for LFCLK then next m_lfclk_wait immediately returns 0 (as if the clock was ready). That is based on an assumption:
The change also affects lfclk request and response APIs, so that new requests or released for the clock will return immediately until the mpsl_clock_ctrl_uninit()_is executed, that resets the sated of the m_lflclk_req_timedout flag.
There is added a Kconfig option:CONFIG_MPSL_EXT_CLK_CTRL- _LFCLK_REQ_TIMEOUT_ALLOW that can be use to disable the workatround.