Need To Use Internal Regulators for 1.8V Operation - How?

[Dan Winker]

We need to use a Lithium Ion battery to power our device and need to connect to a chip that has 1V8 logic levels as its only option.

We're early in development, so it seems like a good first approach would be to hook the L-ion battery to VDDH, have VREGH supply 3.0V? to VREGMAIN (and probably also VREGRADIO) and have those in LDO mode to supply 1.8V to the system.

I see that vregmain, vregradio, and vregh are in the device tree. I'm new to nRF Connect (and using version 2025.9). How do I configure the registers to do what I'm asking?

Thanks

Dan

[Syed Maysum Abbas Zaidi]

Hi,

On nRF5340, VREGMAIN and VREGRADIO are internal regulators that power the cores and radio, and their role is not to set the GPIO logic level. In high‑voltage mode, the GPIO logic level is defined by the VREGH output as shown in this power supply diagram, it can be configured via the UICR.VREGHVOUT register (not via devicetree). You may follow these steps to achieve 1.8 V logic on the GPIOs:

1. Power nRF5340 from the Li‑ion through VDDH pin with the 2.5–5.5 V range (high‑voltage mode).
2. Make sure high‑voltage mode is enabled in the device tree so firmware can configure VREGH:
   

   &vregh {
       status = "okay";
   }

3. Then configure UICR.VREGHVOUT which is programmed at address 0x00FF8010 on nRF5340. Please note that UICR isn’t configured via Kconfig or devicetree. You can run the following command in a terminal once to program the UICR.VREGHVOUT register:
   

   nrfjprog -f nrf53 --memwr 0x00FF8010 --val 0

   
   The values 0 to 5 correspond to 1.8 to 3.3 V as documented in the VREGHVOUT register description.

Kind Regards,
Syed Maysum

[Dan Winker]

Please help with this.

I believe I'm setting LDO mode for vregmain and vregradio correctly, but when I load the code in the debugger and find the VREGMAIN and VREGRADIO registers I see the DCDCEN configuration bit is set for VREGMAIN, VREGRADIO, and VREGH.  This is true at the first breakpoint at main() and still true if I then let it run for a few seconds and pause.

Right now I'm using nRF Connect 2025.9, ncs v3.1.1, and a blue nRF5340-DK board. We will need LDO mode for our product because it is a sensor and we don't have the external inductors that would be needed for DCDC mode.

Build details:

I have two build configurations "ipc_radio" (cpunet) and "sensor" (cpuapp). I end up with a merged_CPUNET.hex and a merged.hex file.

In VSCode, nRF Connect if I select
    APPLICATIONS
        sensor
            build
                sensor

and then
    ACTIONS
        Devicetree Overlay file

I am looking at the result of the Nordic Board File and my overrides in my overlay file. I can click on vregmain and see that my regulator-initial-mode is NRF5X_REG_MODE_LDO, like I want. Similar for vregradio, regulator-initial-mode is NRF5X_REG_MODE_LDO. vregh does not have a regulator-initial-mode option.

Here seems to be the pertient section of build/sensor/zephyr/zephyr.dts ("regulator-initial-mode = < 0x0 >" means LDO I believe):

/dts-v1/;

/* node '/' defined in zephyr/dts/common/skeleton.dtsi:9 */
/ {
...
        /* node '/soc' defined in zephyr/dts/arm/armv8-m.dtsi:6 */
        soc {
...
                /* node '/soc/peripheral@50000000' defined in zephyr/dts/arm/nordic/nrf5340_cpuapp.dtsi:59 */
                peripheral@50000000 {
...
                        /* node '/soc/peripheral@50000000/regulator@4000' defined in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:33 */
                        regulators: regulator@4000 {
                                compatible = "nordic,nrf53x-regulators"; /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:34 */
                                reg = < 0x4000 0x1000 >;                 /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:35 */
                                status = "okay";                         /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:36 */
                                #address-cells = < 0x1 >;                /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:37 */
                                #size-cells = < 0x1 >;                   /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:38 */

                                /* node '/soc/peripheral@50000000/regulator@4000/regulator@4704' defined in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:40 */
                                vregmain: regulator@4704 {
                                        compatible = "nordic,nrf5x-regulator"; /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:41 */
                                        reg = < 0x4704 0x1 >;                  /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:42 */
                                        status = "okay";                       /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:43 */
                                        regulator-name = "VREGMAIN";           /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:44 */
                                        regulator-initial-mode = < 0x0 >;      /* in ../../Git/sensor/build/sensor/zephyr/boards/nrf5340dk_nrf5340_cpuapp.overlay:32 */
                                };

                                /* node '/soc/peripheral@50000000/regulator@4000/regulator@4904' defined in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:48 */
                                vregradio: regulator@4904 {
                                        compatible = "nordic,nrf5x-regulator"; /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:49 */
                                        reg = < 0x4904 0x1 >;                  /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:50 */
                                        status = "okay";                       /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:51 */
                                        regulator-name = "VREGRADIO";          /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:52 */
                                        regulator-initial-mode = < 0x0 >;      /* in ../../Git/sensor/build/sensor/zephyr/boards/nrf5340dk_nrf5340_cpuapp.overlay:36 */
                                };

                                /* node '/soc/peripheral@50000000/regulator@4000/regulator@4b00' defined in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:56 */
                                vregh: regulator@4b00 {
                                        compatible = "nordic,nrf53x-regulator-hv"; /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:57 */
                                        reg = < 0x4b00 0x44 >;                     /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:58 */
                                        status = "okay";                           /* in zephyr/boards/nordic/nrf5340dk/nrf5340_cpuapp_common.dtsi:67 */
                                        regulator-name = "VREGH";                  /* in zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi:60 */
                                };
                        };

I thought maybe I had to set the modes for the ipc_radio build configuration too, but I don't think so.

In VSCode, nRF Connect if I select
    APPLICATIONS
        sensor
            build
                ipc_radio

and then
    ACTIONS
        Devicetree Board File

I get the Devicetree visual editor open in a tab with a warning "Editing SDK file!" I see no icons for vregh, vregmain, or vregradio like I see in the Devicetree visual editor for sensor.

[Syed Maysum Abbas Zaidi]

Hi,

Thanks for the detailed information and for sharing the generated zephyr.dts. We’re currently checking this behavior internally, specifically the interaction between the devicetree regulator-initial-mode settings and the early regulator initialization on the nRF5340 DK.

I’ll get back to you shortly with a correct way to force LDO mode in this setup. Thanks for your patience.

Kind Regards,
Syed Maysum

[Dan Winker]

I got it working and I'm on the verge of learning something here. Can you explain why the process I describe below works?

The best hypothesis I can come up with is

• LDO is the SoC hardware default.
• By default nRF Connect is changing that mode to DCDC (early in startup, controlled by the device tree).
• When I change the mode to LDO in my overlay, the nRF Connect device tree stuff knows LDO is the SoC hardware's default so now nRF Connect just doesn't touch the register.
• The 'west flash --runner jlink' doesn't really reset the SoC, really it just jumps to the entry point or something like that. So, the Soc never initialized the register (or any other registers either?)
• The nRF5340-DK RESET button actually does reset the SoC, so then I get the correct value in the register.

Here's the process I followed to come up with that.

Printing out values of regulator registers at top of main() with and without OVERLAY_MODIFICATION.

---------------OVERLAY_MODIFICATION---------------
&vregmain {
    regulator-initial-mode = <NRF5X_REG_MODE_LDO>;
};

&vregradio {
    regulator-initial-mode = <NRF5X_REG_MODE_LDO>;
};
--------------------------------------------------

Build code without OVERLAY_MODIFICATION

Use 'west flash --runner jlink' which seems to reset the board when it's done (but maybe not exactly?)

I get this expected output:

--------------------------
VREGMAIN:   0x00000001
VREGRADIO:  0x00000001
VREGH:      0x00000001
UICR.VREGHVOUT: 0xffffffff
--------------------------

Build code with OVERLAY_MODIFICATION

Use 'west flash --runner jlink' which seems to reset the board when it's done (but maybe not exactly?)

I get this disappointing output (VREGMAIN and VREGRADIO should both be 0):

--------------------------
VREGMAIN:   0x00000001
VREGRADIO:  0x00000001
VREGH:      0x00000001
UICR.VREGHVOUT: 0xffffffff
--------------------------

Push the RESET button on the nRF5340-DK board

I get the correct output!

--------------------------
VREGMAIN:   0x00000000
VREGRADIO:  0x00000000
VREGH:      0x00000001
UICR.VREGHVOUT: 0xffffffff
--------------------------

[Syed Maysum Abbas Zaidi]

Hi,

Thanks for the detailed follow-up, your investigation seems correct.

On nRF5340, the REGULATORS registers (including the DCDCEN bits) are retained, and the regulators operate in LDO mode by default after a true hardware reset. DC/DC is only enabled if software explicitly sets DCDCEN.

When flashing with west flash --runner jlink, the reset performed over SWD/debug does not always clear retained regulator state. As a result, if a previous image enabled DC/DC, that state can persist and still be visible at the start of main().

And when regulator-initial-mode = NRF5X_REG_MODE_LDO is used, Zephyr does not necessarily rewrite the register, since LDO already matches the hardware default. Pressing the RESET button on the nRF5340-DK performs a full hardware reset, returning the regulators to their default LDO state, which is why you then see the expected values.

So your configuration is correct, the behavior you observed is due to retained regulator state and reset type, not a missing devicetree or Kconfig setting. Thanks for pointing this out.

Best Regards,
Syed Maysum