nRF5340 - frequency set API

[koffes]

There should be an API to set the APP core freq of the nRF5340.

Currently, the method of changing the core freq is direct register writes.

This API should:

• Change the clock between 64 and 128 MHz.
• Take relevant PANs into account.
• Ensure that timers respond correctly to the clock change. Changing the frequency during execution will generate a number of difficult issues. An alternative to run-time changing is to have a CONFIG which executes the change prior to kernel start.

@ioannisg

[mmajchrzycki]

You can do it by using the following function (from nRF Connect SDK):

#include <nrfx_clock.h>

nrfx_clock_divider_set(NRF_CLOCK_DOMAIN_HFCLK, NRF_CLOCK_HFCLK_DIV_1);

[koffes]

Thanks, we are already using that one. Though, this may cause timer issues as Zephyr is not aware that the CPU has changed its base frequency. This may impact logging, scheduling, etc. This should be a Zephyr level API.

[anangl]

nrfx_clock_divider_set() calls SystemCoreClockUpdate(), so Zephyr is actually aware of the change. And I am not sure what "timer issues" you mean. The TIMER peripherals are driven by a peripheral clock that is not affected by the change of the core clock divider and the kernel timers are driven by the LFCLK clock that Zephyr uses as its system clock, which is not affected as well (so I don't see any impact on logging or scheduling). Only the SysTick timer is affected by the core clock frequency change.

[koffes]

I see now that just 14 days after I opened this issue, you added the SystemCoreClockUpdate() @anangl :)

So, I take it as Zephyr is aware of the change, or rather does not need to be aware of the change, we can alter between 64 and 128 MHz whenever we want? The "timer issues" was a concern from my side, as we originally did a call directly to nrfx without Zephyr knowing that any change had been made. This could potentially lead to a number of issues, depending on how the system is constructed.

[nordic-krch]

@anangl i think that k_busy_wait will be affected.

[anangl]

@anangl i think that k_busy_wait will be affected.

Yes, but it calls nrfx_coredep_delay_us() that takes SystemCoreClock into account, so the delay time will be almost the same (only the overhead of calling the function will be a bit lower for the core working with the higher clock).

[nordic-krch]

@anangl right, i missed that it takes SystemCoreClock for delay calculation.

[koffes]

FYI: @alexsven.

I will close this issue as no one seems to see any issue with this.