How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Fri, 20 Mar 2026 06:02:40 GMT

Thank you for the kind words. It's great to have happy customers. Have a great weekend too!

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Thu, 19 Mar 2026 23:54:17 GMT

Thanks Vidar for all of your help throughout this conversation. It was a pleasure talking with you. Hopefully others will find this discussion helpful as well.

Have a great weekend!

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Wed, 18 Mar 2026 07:44:04 GMT

Hi Ken,

Sorry I forgot to comment on the programming part. Yes, please continue using the Programmer app. To flash a device, the extension simply calls "west flash", so the supported programming method is defined by the board file and what is available in the SDK and currently we do not support programming over DFU. In other words, programming via the extension is only available if you have an external debug probe connected to your dongle.

Best regards,

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Tue, 17 Mar 2026 20:58:39 GMT

Hi Vidar,

The code you proposed worked and I confirmed that REGOUT0 is set for 3V0. However, I think this particular nRF52840 Dongle must have been damaged somewhere along the way as its VDD_OUT remains at 3.5V.

A question from earlier: Is there a way to program the Dongle through the nRF Connect SDK VS Code or should I continue to use the Programmer?

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Mon, 16 Mar 2026 06:59:09 GMT

Hi Ken,

Glad to hear that it worked. The nrf52840dongle board target has always enabled console output on USB, what is new is that the VS code extension will now recognise it as a development board and list it under CONNECTED DEVICES. Previously you would have to manually find and select the correct COM port.

To use RTT you would need to have an external debug probe connected to your dongle.

[quote user="Ken58"] A very quick check of this with a nRF52840DK looks like the RTT connection has gone away.[/quote]

Maybe something changed in the UI? I know the RTT feature has not been removed, at least.

[quote user="Ken58"]However, I need to call this code in place of board_early_init_hook(). How would you recommend I do that? [/quote]

I don't think you need to call it in place of the board_early_init_hook() function. You could try calling the function below at the beginning of your main().

#include <soc.h>

void reg0_update(void)
{
    /* Check if REGOUT0 is currently configured to output 3v3 */
    if ((NRF_UICR->REGOUT0 & UICR_REGOUT0_VOUT_Msk) ==
        (UICR_REGOUT0_VOUT_3V3 << UICR_REGOUT0_VOUT_Pos))
    {
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy);
        NRF_UICR->REGOUT0 =
            (NRF_UICR->REGOUT0 & ~((uint32_t)UICR_REGOUT0_VOUT_Msk)) |
            (UICR_REGOUT0_VOUT_3V0 << UICR_REGOUT0_VOUT_Pos);

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy);
        /* a reset is required for changes to take effect */
        NVIC_SystemReset();
    }
}

Best regards,

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Sun, 15 Mar 2026 23:15:26 GMT

Hi Vidar,

Logging from the nRF52840 Dongle works great! How long has this been available? Last I had looked at it, the nRF Connect SDK did not connect to a Dongle through the CONNECTED DEVICES view at all. Could or should RTT be used, or has this changed recently too? A very quick check of this with a nRF52840DK looks like the RTT connection has gone away.

Is there a way to program the Dongle through the nRF Connect SDK or should I continue to use the Programmer?

I learned that my nRF52840 Dongle that has the 3.5V output voltage does indeed have it's REGOUT0 set to 3V3. I understand the process involved in setting this back to 3V0. However, I need to call this code in place of board_early_init_hook(). How would you recommend I do that? I tried including it in my code but the build process with fail with a multiple definition of 'board_early_init_hook'. I probably don't want to modify the code in the SDK. There is probably a better way.

Thank you,

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Wed, 11 Mar 2026 06:42:46 GMT

The nrf52840Dongle/nrf52840 board target enables the USB by default so you shouldn't have to change anything to make this work. To test you can try the "Hello World" sample and print something in a loop.

Relevant devicetree entries

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Tue, 10 Mar 2026 20:23:38 GMT

I will have to check. Is there anything in the Nordic documentation that would tell me all the DeviceTree and Kconfig setup I need to have?

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Wed, 04 Mar 2026 12:41:15 GMT

It should be supported out of the box. Is your dongle not enumerating as a USB CDC device when you plug it in?

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Wed, 04 Mar 2026 01:14:53 GMT

Thanks Vidar. Is there an easy way to get log info from an nRF52840 Dongle?

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Tue, 03 Mar 2026 07:27:50 GMT

Hi Ken,

The only scenario in high voltage mode where I can see it getting close to 3.5V is if REGOUT0 is configured to 3v3 and you add the +5% worst case accuracy deviation.

[quote user="Ken58"]What if back in 2018 for example, REGOUT0 was set permanently with option value 6, the missing value in the list of possible values. Was there an 3V5 option?[/quote]

3v3 has always been the maximum and our SDK code (both new and old) has been setting the register to 3.0v.

(https://docs.nordicsemi.com/bundle/ps_nrf52840/page/power.html#ariaid-title74)

[quote user="Ken58"] I don't know if that matters, but they are missing resistor R7, a 47 ohm series resistor between VBUS and VDDH.[/quote]

This is interesting. I was not aware of this. Maybe this can explain why you didn't observe the same spike when testing with the DK. The series resistor was added in revision 2.0.0 of the DK.

Also from the "Reference circuitry" chapter of the Product specification:

The schematics include an optional series resistor on the USB supply for improved immunity to transient overvoltage during VBUS connection. Using the series resistor is recommended for new designs.

[quote user="Ken58"]Is there any code available in the SDK that would allow me to easily erase the UICR, and then execute code like in board_early_init_hook() to set REGOUT0 to 3V on my 3V5 Dongle?[/quote]

There isn't any existing code for this unfortunately. But maybe you can read out the register before making any attempts on this.

#include <soc.h>

...

    LOG_INF("NRF_UICR->REGOUT0: %d", NRF_UICR->REGOUT0);

Best regards,

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Mon, 02 Mar 2026 22:08:41 GMT

Hi Vidar,

Thanks on the board_early_init_hook() function info. Now, the 3V makes sense.

On the 3.5V dongle: All of my nRF52840 dongles are ancient V1.0.0 hardware. None have been modified for the supply configuration. I don't know if that matters, but they are missing resistor R7, a 47 ohm series resistor between VBUS and VDDH.

In board_early_init_hook(), if REGOUT0 is not set with the DEFAULT value, it will not try to set REGOUT0 to 3V. Furthermore, since board_early_init_hook() does not erase the UICR, it will successfully set REGOUT0 a maximum of twice for any particular nRF52804 Dongle. What if back in 2018 for example, REGOUT0 was set permanently with option value 6, the missing value in the list of possible values. Was there an 3V5 option?

Is there any code available in the SDK that would allow me to easily erase the UICR, and then execute code like in board_early_init_hook() to set REGOUT0 to 3V on my 3V5 Dongle?

Best regards,

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Mon, 02 Mar 2026 07:44:57 GMT

Hi Ken,

REGOUT0 is a non-volatile register and you need to erase the UICR section (ERASEUICR) before you can update it to a different setting. In the case where the dongle is not running the pre-programmed FW, the REGOUT0 register will be updated by the board init function here: https://github.com/nrfconnect/sdk-zephyr/blob/f80011480a2208ddbfb2decad3e3d9dab078c548/boards/nordic/nrf52840dongle/board.c#L12

[quote user="Ken58"]A sidebar to that question: I have a particular nRF52840 Dongle whose output voltage running the same application as we have been talking about is 3.5V. That's a little weird! Any idea on what might cause that?[/quote]

Yes, this does not make sense. The REG0 regulator cannot output more than 3v3 according to the specification. Have you made any changes to the dongle's supply configuration by any chance (https://docs.nordicsemi.com/bundle/ug_nrf52840_dongle/page/UG/nrf52840_Dongle/hw_power_supply.html)?

Best regards,

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Sun, 01 Mar 2026 16:48:34 GMT

Hi Vidar,

I had tried the pull-down resistor before using a rather high value (10k) without success. Using a lower value resistor (2.2k) seems to allow dissipation of the startup pulse without switching on the transistor. This becomes a balancing act to keep the "on" circuit current minimized and still pulling enough current on startup to pull down the pulse. Never the less, this conversation helped me ensure there was nothing else in the software I could or should do to prevent the pulse.

A related question or 3 from our discussion: You said "The pre-programmed FW on the dongle sets it to 3v to be able to drive the on-board RGB LED". Where does this happen and can I easily set REGOUT0 to a different value within a Zephyr application on the nRF52840 Dongle? Is there a system initialization function where this could be done, or DeviceTree parameter used by Zephyr? What would be your recommended method?

A sidebar to that question: I have a particular nRF52840 Dongle whose output voltage running the same application as we have been talking about is 3.5V. That's a little weird! Any idea on what might cause that?

I will probably have a related question or 2 concerning a custom board, but I'm not ready to ask yet.

Thanks,

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Mon, 23 Feb 2026 08:28:14 GMT

Hi Ken,

I discussed this with one of my more hardware oriented coworkers who suggested adding an external pull-down resistor between the GPIO pad and the transistor gate to ensure the signal is not floating on startup.

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Sat, 21 Feb 2026 19:37:03 GMT

Probing other GPIOs shows similar pulses. Looking around the internet, I see indications that this is not uncommon on MCUs in general, though I haven't found a specific instance of Nordic SOCs. Could you ask one of your EEs to comment on this? If the pulse cannot be eliminated through setup within the application software, what would be the recommended method of connecting a GPIO port to other electronics - say a simple case of interfacing to a transistor operating as a switch?

I'll add a couple more pics. As above, the yellow trace is the nRF52840 Dongle GPIO pin (P0.13). In these new images, blue is the 5V supply from my electronics going into VBUS on the dongle. The second pic is zoomed in on the area of interest.

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Fri, 20 Feb 2026 07:12:15 GMT

Hi Ken,

I'm wondering if you are simply seeing noise because the inputs are high-z. To be honest, I am not entirely sure what to expect here, but I know that USB ports can be quite noisy. Have you tried probing other unused pins on the dongle to see if they exhibit similar behaviour?

[quote user="Ken58"] I did note that VDD is now about 1.8V vs. 3V when powered as before.[/quote]

Yes, default is 1.8. It is controlled by the REGOUT0 register. The pre-programmed FW on the dongle sets it to 3v to be able to drive the on-board RGB LED.

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Wed, 18 Feb 2026 21:38:49 GMT

Hi Vidar,

I did the following with the nRF52840 DK: Set SW9 to USB and plugged the USB cable into J3. I did not modify the application software. Powering the board on and off via plugging/unplugging the USB cable into my PC USB port does not produce anything weird on the GPIO pin I've been monitoring. It seems well behaved as before. I did note that VDD is now about 1.8V vs. 3V when powered as before.

Also, a couple more screen shots from my scope showing the weird pulse seen on GPIO P0.13 when plugging in the nRF52840 Dongle, zoomed in on the second pic. I'm assuming the 60Hz noise is expected.

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Mon, 16 Feb 2026 09:16:58 GMT

Hi Ken,

Thank you, likewise. With the DK board switches in their default positions and the USB cable connected to the J2 port, the nRF52840 will be supplied with 3 V regulated from the USB bus in normal voltage mode while the dongle is powered directly from the USB in high voltage mode. Perhaps this explains the different behaviour. Could you please try supplying the nRF52840 DK from the nRF USB to see if you get the same result?

https://docs.nordicsemi.com/bundle/ug_nrf52840_dk/page/UG/dk/power_source.html

Best regards,

Vidar

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Ken58 — Sun, 15 Feb 2026 01:31:57 GMT

Hi Vidar,

I can run my application on both the nRF52840DK and nRF52840 Dongle although I am using different pins (P1.06 and P0.13 respectively) to connect with the rest of my electronics. Using the debugger and the DK, I have checked with that my PIN_CNF register value for the GPIO pin I am using is set as you show: Input and Disconnect. I checked DeviceTree as well. Monitoring the DK pin with a scope, turning the DK on via the SW8 power switch, the GPIO pin remains stable and at 0V through the power on reset and boot. On the other hand, when plugging the Dongle into a USB cable, the GPIO pin shows a spike and oscillating voltage as shown in the attached picture. I think this is the root of the problem I am trying to solve. Why is the Dongle producing this GPIO pin voltage during the power on reset and boot? I have seen no evidence of this from the DK.

Best regards, and good to talk with you again,

Ken

RE: How to ensure an nRF52840 GPIO pin is disconnected at powerup via the DeviceTree board overlay file?

Vidar Berg — Tue, 10 Feb 2026 07:07:48 GMT

Hello Ken,

On startup after a power-on-reset, all GPIOs are configured to their reset state (“disconnected input”), so you should not need to do anything to avoid spurious signals at startup. If this is not what you are seeing, perhaps it could be that the pin may be assigned to a peripheral or a driver in the device tree and is being reconfigured during driver initialisation?

(PIN_CNF[0])

"Wakeup from System OFF mode reset" is the only reset source which will not reset the GPIO registers.

Best regards,

Vidar