When building the blinky sample with CONFIG_CLOCK_CONTROL_NRF=y set in prj.conf, the build doesn't enable the clock control and gives this warning:
warning: CONFIG_CLOCK_CONTROL_NRF was assigned the value 'y' but got the value 'n'. Missing dependencies: DT_HAS_NORDIC_NRF_CLOCK_ENABLED
Steps to reproduce
- Start from the blinky sample targeting
nrf52dk_nrf52832. - Add the following to prj.conf:
CONFIG_CLOCK_CONTROL_NRF=y CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
- Add the following board overlay (nrf52dk_nrf52832.overlay)
&clock { status = "okay"; };
Expected behavior
CONFIG_CLOCK_CONTROL_NRF should be satisfied since the clock node exists on the nRF52832 and is explicitly enabled via the overlay.
Actual behavior
DT_HAS_NORDIC_NRF_CLOCK_ENABLED is not being derived from the devicetree, so CONFIG_CLOCK_CONTROL_NRF falls back to n
Inspecting devicetree_generated.h confirms the clock node is correctly resolved in the devicetree:
#define DT_COMPAT_HAS_OKAY_nordic_nrf_clock 1 #define DT_N_S_soc_S_clock_40000000_COMPAT_MATCHES_nordic_nrf_clock 1 #define DT_N_INST_0_nordic_nrf_clock DT_N_S_soc_S_clock_40000000
The node is present and status = "okay", so DT_HAS_NORDIC_NRF_CLOCK_ENABLED should be satisfied. However, Kconfig still reports it as a missing dependency for CONFIG_CLOCK_CONTROL_NRF.
This suggests the issue is not in the devicetree itself, but in how DT_HAS_NORDIC_NRF_CLOCK_ENABLED is generated or consumed during the Kconfig evaluation phase in NCS 3.1.1. This may be a build system regression or a change in how DT-to-Kconfig symbol mapping works in this release.
Questions
- Is
DT_HAS_NORDIC_NRF_CLOCK_ENABLEDexpected to be auto-set for this board, or does something else need to change in the overlay/board files? - Is this a regression in NCS 3.1.1?
