Describe the bug
Since PR #86354, my application can't activate the HF clock source (external HF crystal) with clock_control_on() when the crystal is physically off. The error code -EPERM (-1) is returned.
Actually, the internal flags state is set to 2 which means CLOCK_CONTROL_STATUS_ON. That's the reason why clock_control_on() returns -1. However, the clock control state is wrong. I have checked the CLOCK register and crystal itself. It is off.
The reason for CLOCK_CONTROL_STATUS_ON is the call of clkstarted_handle() here
|
#if NRF_CLOCK_HAS_XO_TUNE |
|
case NRFX_CLOCK_EVT_XO_TUNED: |
|
clkstarted_handle(dev, CLOCK_CONTROL_NRF_TYPE_HFCLK); |
|
break; |
clkstarted_handle() enforces that the internal
flags state is set to
CLOCK_CONTROL_STATUS_ON. Somehow that state is never reset to
CLOCK_CONTROL_STATUS_OFF.
I could "fix" this issue when I replaced the current implementation with the old one that checked if the current state is CLOCK_CONTROL_STATUS_STARTING which make sense IMHO.
|
{ |
|
struct nrf_clock_control_sub_data *data = |
|
get_sub_data(dev, CLOCK_CONTROL_NRF_TYPE_HFCLK); |
|
|
|
/* Check needed due to anomaly 201: |
|
* HFCLKSTARTED may be generated twice. |
|
*/ |
|
if (GET_STATUS(data->flags) == CLOCK_CONTROL_STATUS_STARTING) { |
|
clkstarted_handle(dev, CLOCK_CONTROL_NRF_TYPE_HFCLK); |
|
} |
|
|
|
break; |
I didn't check if the clock is handled really correctly with this work-around. I have just noticed that with this fix
clock_control_on() and
clock_control_off() work as expected.
I use these feature for crystals frequency checking in production. Unable to enable the crystal permanently is a release blocker for me.
Regression
Steps to reproduce
Not entirely sure what is really required to reproduce. I have ...
- Bluetooth application in advertising mode
- Stop BT advertising
- Call
clock_control_on(CLOCK_DEVICE, CLOCK_CONTROL_NRF_SUBSYS_HF);
Relevant log output
Impact
Showstopper – Prevents release or major functionality; system unusable.
Environment
- Zephyr 4.2
- Nordic nRF54L15
Additional Context
No response
Describe the bug
Since PR #86354, my application can't activate the HF clock source (external HF crystal) with
clock_control_on()when the crystal is physically off. The error code-EPERM(-1) is returned.Actually, the internal
flagsstate is set to2which meansCLOCK_CONTROL_STATUS_ON. That's the reason whyclock_control_on()returns -1. However, the clock control state is wrong. I have checked the CLOCK register and crystal itself. It is off.The reason for
CLOCK_CONTROL_STATUS_ONis the call ofclkstarted_handle()herezephyr/drivers/clock_control/clock_control_nrf.c
Lines 703 to 706 in 0f66e9c
clkstarted_handle()enforces that the internalflagsstate is set toCLOCK_CONTROL_STATUS_ON. Somehow that state is never reset toCLOCK_CONTROL_STATUS_OFF.I could "fix" this issue when I replaced the current implementation with the old one that checked if the current state is
CLOCK_CONTROL_STATUS_STARTINGwhich make sense IMHO.zephyr/drivers/clock_control/clock_control_nrf.c
Lines 719 to 730 in c326bf6
I didn't check if the clock is handled really correctly with this work-around. I have just noticed that with this fix
clock_control_on()andclock_control_off()work as expected.I use these feature for crystals frequency checking in production. Unable to enable the crystal permanently is a release blocker for me.
Regression
Steps to reproduce
Not entirely sure what is really required to reproduce. I have ...
clock_control_on(CLOCK_DEVICE, CLOCK_CONTROL_NRF_SUBSYS_HF);Relevant log output
Impact
Showstopper – Prevents release or major functionality; system unusable.
Environment
Additional Context
No response