Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: clock_control: nrf: Use synthesized LF clock source in tests #24972

Closed
wants to merge 1 commit into from
Closed

drivers: clock_control: nrf: Use synthesized LF clock source in tests #24972

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion drivers/clock_control/Kconfig.nrf
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,8 @@ if CLOCK_CONTROL_NRF

choice CLOCK_CONTROL_NRF_SOURCE
prompt "32KHz clock source"
default CLOCK_CONTROL_NRF_K32SRC_XTAL
default CLOCK_CONTROL_NRF_K32SRC_XTAL if !ZTEST
default CLOCK_CONTROL_NRF_K32SRC_SYNTH if ZTEST
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pabigot @andyross @nordic-krch

Since the assumption that k_busy_wait() and k_sleep() are driven by the same clock is just not valid for Nordic platfroms (and likely for others as well, present or future), would it be better to introduce a new FREQUENCY_TOLERANCE variable that the test uses to extend its tolerance and that can be set to 0 for platforms that use the same clock.
Then you can have something like: check_timeout_drift() that uses FREQUENCY_TOLERANCE in all tests that combine busy waits with sleep.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andyross could you please weigh in here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments in #24784 (comment) -- I'd be personally happy with this patch, or its converse.

To nitpick: I guess stylewise I'd prefer a choice of name that conveys the implication and not just the details. The important thing to an app isn't what whether the source is "SYNTH" or "XTAL", it's that the "synth" choice is subject to temperature and semiconductor process skew where the crystal is tuned to more conventional tolerances.

As far as adding code to the test framework, that would work, but it doesn't seem much different than just adding a fudge factor for individual cases. These kind of long busy waits are pretty rare even in the tests.


config CLOCK_CONTROL_NRF_K32SRC_RC
bool "RC Oscillator"
Expand Down