Change CPU frequency of nRF54L15

[Emil Lenngren]

The OSCILLATORS documentation says:

"The device starts at 64 MHz. For 128 MHz, it must be configured when the CPU starts and before any peripherals that use the high-frequency clock are enabled. Changing the frequency on a running system or to an unsupported value causes undefined system behavior and the device can malfunction."

Furthermore, the configuration register is retained.

Let's assume we perform a firmware update of a device in the field and the device reboots (soft reset). With the new firmware version, it is configured to use a different CPU frequency than the previous firmware. The boot code of the firmware will then change the frequency of a running system, which causes undefined system behavior according to the documentation. So is it really not allowed to use different CPU frequencies for different firmware versions like this? Any workarounds? Or would this work fine in practice (i.e. change CPU frequency after soft reset)?

And what about if the bootloader happens to use a different CPU frequency than the application?

[Kenneth]

Hi,

I am wondering if this is more of a theoretical problem rather than actual problem, because I would expect you want to run on 128MHz always. Considering the nRF54L15 don't have any Dynamic Voltage-Frequency Scaling I would expect the most power efficient would be to run on 128MHz and execute the task in half the time compared to 64MHz, or do you see scenarios where using 64MHz could be beneficial here.

I can find in \modules\hal\nordic\nrfx\mdk\system_nrf54l.c I it's configured to 128MHz in SystemInit(), I would expect this is the case for all images if not explicit changed.

Kenneth

[Emil Lenngren]

For CPU intense workloads, then yes, the 128 MHz frequency might be more optimal.

But when the MCU domain must be kept on due to some timing requirement, e.g. while busy-looping when waiting for a short SPI transfer to finish, or GRTC to wake up when requesting the current time, the 128 MHz option will of course consume more energy.

But in particular, due to these erratas https://docs.nordicsemi.com/bundle/errata_nRF54L15_Rev1/page/ERR/nRF54L15/Rev1/latest/anomaly_L15_39.html and https://docs.nordicsemi.com/bundle/errata_nRF54L15_Rev1/page/ERR/nRF54L15/Rev1/latest/anomaly_L15_20.html, the MCU domain will also need to stay on while using the radio. For example, during a radio reception like a BLE scan, according to my measurements, the system consumes around 11% more power with 128 MHz than if those errata would not exist and with 64 MHz, only around 8% more.

So yes, depending on the application, the optimal clock frequency is different for different scenarios.

And when I look in system_nrf54l.c, I see that the clock configuration can be changed using a define.

[PaKa]

Bluetooth stack is only qualified with 128MHz so when using Bluetooth you have to run 128MHz.

[Kenneth]

I will ask internally to check if any of the designers can comment a bit on when CPU frequency can be safely changed or not.

Kenneth

[Emil Lenngren]

PaKa said:

Bluetooth stack is only qualified with 128MHz so when using Bluetooth you have to run 128MHz.

Where is this documented?

[Kenneth]

Looks like it will cause a build error moving forward if not using 128MHz, ref:
https://github.com/nrfconnect/sdk-nrf/commit/9529161739fab464d5337edccf16ab4f54d9b310 

There are no plans to support 64MHz.

They will add a note in the documentation that 128MHz should be used for the softdevice controller, so I guess overall it looks like 64MHz indirectly isn't supported by software.

Kenneth