How to modify the low-speed crystal oscillator type and power supply mode in the code？

[Август]

NCS2.7.0

board：nrf54L15

We need a hardware to equip the nrf54l15 hardware, such as using internal or external low-speed crystal, power supply method is DCDC or LDO, etc.

Just like the old SDK, you can modify these in the code, but ncs can change it in the configuration file.

eg：

1. burn param to uicr

2. read uicr param 

3. code set param（xtal rc or dcdc ldo）

 

 change dcdc or ldo

old SDK

sd_power_dcdc_mode_set （NRF_POWER_DCDC_ENABLE ）

change xtal or rc

old SDK

I can modify clock_lf_cfg to decide whether to use internal or external crystal.

sd_softdevice_enable （＆clock_lf_cfg，app_error_fault_handler）；

I found that ncs uses clock control, but I don't know how to change it. Please give me some suggestions.

I tried restarting the clock this way but I don't know if it's possible.

[Einar Thorsrud]

Hi,

To use LFRC instead of LFXO use this in your Kconfig (for instance in prj.conf or in a board configuratin file if you have that for your custom board):

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

(The DK borad files will use crystal by default, by setting CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y)

To use DCDC, include BOARD_ENABLE_DCDC=y in the configuration when using nRF Connect SDK 2.7.0 or earlier. Also use the following for nRF54L (and other boards in main or SDK 2.8.0 or later):

&vregmain {
	status = "okay";
	regulator-initial-mode = <NRF5X_REG_MODE_DCDC>;
};

(If using LDO use NRF5X_REG_MODE_LDO instead of  NRF5X_REG_MODE_DCDC).

[Август]

Hi,

   Thanks for your quick response. 

   I need an interface to modify the low speed crystal type.

   Because our project one firmware is needed for multiple hardware.

  eg：

void main (void)
{
    /* dcdc */
    uint8_t dcdc_type = 0;
    dcdc_type = read_dcdc_type_from_flash(); /* just a example */
    NRF_REGULATORS->VREGMAIN.DCDCEN = dcdc_type;
    
    /* xtal or rc(ppm) */
    
}

[Август]

One firmware for multiple hardware
For example, a hardware with an external low-speed crystal oscillator and dcdc
a hardware with an external low-speed crystal oscillator and ldo
a hardware without an external low-speed crystal oscillator and dcdc
a hardware without an external low-speed crystal oscillator and ldo

[Einar Thorsrud]

Hi,

This is configured at build time in the SDK, and when it comes to DCDC it is not possible to know beforhand if the DCDC inductors are mounted before switching to DCDC, and if you do and the DCDC inductors are missing, the device will become unresponsive. When it comes to clock configuration it is technically possible from a HW perspective to detect if a LFXO is present by attempting to start it and wait for some time (based on the HF clock) to see if it starts, and rever to LFRC if not. But this is not supported in the SDK (or Zephyr).

So the proper solution here is to specify separate boards or use board overlay fiels to build variants that suit the different hardware variations you have, and use the correct build for each board.

[Август]

Hi，

   Thanks for your response.

    We know whether the board has LFXO and dcdc, so we can burn the parameters into UICR first when burning and then use uicr param set param.

Is it possible to reconfigure parameters during initialization?

If this is really not possible, I can also use your answer to convince my boss to make multiple firmwares for adaptation.

Thanks

[Einar Thorsrud]

Hi,

I see. If you can check in UICR, then you can make a decision based on UICR content. This is not directly supported, but you can modify power_and_clock_configuration() in zephyr/soc/nordic/nrf54l/soc.c (this is part of the SDK and is expected to change going forward).

When it comes to clcok control this is also a decition made by Kconfig during build and in code it id used by the Zephyr clock control driver in zephyr/drivers/clock_control/clock_control_nrf.c and when initializing MPSL in nrf/subsys/mpsl/init/mpsl_init.c. I see no direct techincal reason why you cannot modify this to do it dynamically, but it will require some changes to the SDK that you will have to handle and maintain over time.

I would argue that using separate board fiels and/or overlay files for separate HW variants is cleanest, and that is how this is intended to be handled.