Retained register

RE: Retained register

Gmrck — Wed, 07 Jan 2026 20:53:15 GMT

Thanks a lot, Einar! It works for me this way.

RE: Retained register

Einar Thorsrud — Mon, 05 Jan 2026 14:03:27 GMT

Hi,

I see. That should not matter though, and I also have no problems when I test like this:

/* main.c - Application main entry point */

/*
 * Copyright (c) 2015-2016 Intel Corporation
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/types.h>
#include <stddef.h>
#include <zephyr/sys/printk.h>
#include <zephyr/sys/util.h>

#include <zephyr/bluetooth/bluetooth.h>
#include <zephyr/bluetooth/hci.h>

#include <hal/nrf_power.h>

int main(void)
{
	int err;

	printk("Starting Beacon Demo\n");

	/* Initialize the Bluetooth Subsystem */
	err = bt_enable(NULL);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
	}

	printk("GPREGRET0: 0x%08X\n", nrf_power_gpregret_get(NRF_POWER, 0));
	printk("GPREGRET1: 0x%08X\n", nrf_power_gpregret_get(NRF_POWER, 1));

	return 0;
}

static int retention_registers_increment(void)
{
	uint32_t gpregret0_val = nrf_power_gpregret_get(NRF_POWER, 0);
	uint32_t gpregret1_val = nrf_power_gpregret_get(NRF_POWER, 1);

	gpregret0_val++;
	gpregret1_val++;

	nrf_power_gpregret_set(NRF_POWER, 0, gpregret0_val);
	nrf_power_gpregret_set(NRF_POWER, 1, gpregret1_val);

	return 0;
}

SYS_INIT(retention_registers_increment, PRE_KERNEL_1, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT);

RE: Retained register

Gmrck — Tue, 23 Dec 2025 19:43:57 GMT

Hi, Einar,

Thanks for your answer. I think the only difference of your code and mine is that you access the registers in your main function on the APPLICATION stage, but in my case I've accessed them in a function which is run on a PRE_KERNEL_1 stage.

RE: Retained register

Einar Thorsrud — Wed, 17 Dec 2025 15:20:28 GMT

Hi,

I am sorry for the late reply.

Normally both GPREGRET registers are available and usable. I tested with a modified beacon sample from SDK 3.2 with updated main function like this and see that both are incremented as expected after reset, without any errors. If this still do not work on your end, we need to look more closely at what you do in your design.

#include <hal/nrf_power.h>

int main(void)
{
	int err;

	printk("Starting Beacon Demo\n");

	uint32_t gpregret0_val = nrf_power_gpregret_get(NRF_POWER, 0);
	uint32_t gpregret1_val = nrf_power_gpregret_get(NRF_POWER, 1);

	/* Initialize the Bluetooth Subsystem */
	err = bt_enable(bt_ready);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
	}

	printk("GPREGRET0: 0x%08X\n", gpregret0_val);
	printk("GPREGRET1: 0x%08X\n", gpregret1_val);

	gpregret0_val++;
	gpregret1_val++;

	nrf_power_gpregret_set(NRF_POWER, 0, gpregret0_val);
	nrf_power_gpregret_set(NRF_POWER, 1, gpregret1_val);

	return 0;
}

RE: Retained register

hmolesworth — Tue, 09 Dec 2025 17:14:38 GMT

As an aside, note there are other registers which are retained and could be used for data when the associated peripheral is not used on a particular design (taking care to avoid side-effects of course). Some mapping is required as the bits within the registers are not contiguous. Retained registers on the nRF52832:

GPIO: The PIN_CNF registers are retained registers
LPCOMP: All LPCOMP registers, including ENABLE, are classified as retained registers when the LPCOMP is enabled. However, when the device wakes up from System OFF, all LPCOMP registers will be reset

RE: Retained register

Gmrck — Tue, 09 Dec 2025 10:08:38 GMT

Hi, Einar,

Thanks for the hint. It indeed makes sense to have a single API function for that.
Quick question though: the reg number is 0 and 1, right? Where 0 stands for GPREGRET1 and 1 for GPREGRET2? Seems logical, but wanted to confirm.
Are there any restrictions on when GPREGRET2 becomes available boot cycle-wise? I've tried the direct access to it at PRE_KERNEL_1 stage, and it wasn't available - the app hung, while the GPREGRET1 was accessible and I was able to write into it. As far as I know the GPREGRET1 is used by the DFU, while GPREGRET2 is free for use with no chance of it being used by any internal nordic things, like DFU, correct?

RE: Retained register

Einar Thorsrud — Tue, 09 Dec 2025 08:09:13 GMT

I see. That is not the case, though. If you compare the old nrf_power_gpregret_set() and nrf_power_gpregret2_set() you can see it takes two parameters. The new nrf_power_gpregret_set() takes three parameters, where one is the register number. So instead of having separate API functions for each GPREGRET register, the same is used for all.

RE: Retained register

Gmrck — Mon, 08 Dec 2025 16:11:05 GMT

Thanks for the confirmation, Einar. It is just confusing, that we do have nrfx functions for one, but not for another, which made me thinking the support for the GPREGRE2 was dropped. Especially, that there is a line
"This register is not available in all MCUs."
in the https://docs.nordicsemi.com/bundle/ncs-2.0.1/page/nrfx/drivers/power/hal.html documentation.

RE: Retained register

Einar Thorsrud — Mon, 08 Dec 2025 15:46:09 GMT

It does not specifically mention gpregret1 or gpregret2 in the API documentation, but both are there (gpregret2 here).

RE: Retained register

Gmrck — Mon, 08 Dec 2025 15:35:59 GMT

This documentation doesn't have any mentioning of the GPREGRET2:

https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/group_nrf_power_hal.html

While the earlier version of SDK documentation has it mentioned here
https://docs.nordicsemi.com/bundle/ncs-2.0.1/page/nrfx/drivers/power/hal.html
as functions to access the value:
NRF_STATIC_INLINE void nrf_power_gpregret2_set(NRF_POWER_Type *p_reg, uint8_t val)
and
NRF_STATIC_INLINE uint8_t nrf_power_gpregret2_get(NRF_POWER_Type const *p_reg)

This is where the confusion comes, as in the latest documentation of SDK or nrfx I am not able to see any mentioning of gpregret2 as a register or any mentioning of a function to use to write to this register.

RE: Retained register

Einar Thorsrud — Mon, 08 Dec 2025 15:20:24 GMT

From what I can see GPREGRET2 is defined also in the latest SDK version. Can you clarify exactly where you see GPREGRET2 missing (file and line) and which versions you are comparing?

RE: Retained register

Gmrck — Mon, 08 Dec 2025 15:08:37 GMT

Einar, btw, what has changed to the GPREGRET2 in the nrfx library? I no longer see it or its functions there in the latest version. Though, the board files have both gpregret and gpregret2 as the devices available in the device tree.

RE: Retained register

Gmrck — Mon, 08 Dec 2025 13:51:09 GMT

Thanks, Einar. I guess this is exactly what I was looking for.

RE: Retained register

Einar Thorsrud — Mon, 08 Dec 2025 09:55:54 GMT

Hi,

Please see this post.

RE: Retained register

Gmrck — Sun, 07 Dec 2025 12:11:36 GMT

Hi, Einar! Are there any examples of how to write & read to & from the GPREGRET2 register the best way in nrfConnect SDK 3.0?
This works for me:

NRF_POWER->GPREGRET = gpregretValue;

However, as soon as it is:

NRF_POWER->GPREGRET2 = gpregretValue;

The program doesn't go into the main loop, so I guess it is failing with this one. I am on nrf52840DK the latest revision.
I do this on PRE_KERNEL_1 level.

Could you please share the best practices of handling these registers? The nrfx HAL contained some functions for that, but I believe they were dropped closer to SDK 3.0. And I can't find anything in the latest documentation on it.

RE: Retained register

Einar Thorsrud — Tue, 02 Sep 2025 12:56:12 GMT

Hi,

The GPREGRET registers are the only supported way to retain data that is not in flash during a reset. Other than that, the only approach that works reliably is to store the data in flash. However, you can also store data data in non-initialized RAM together with a checksum and read that data after reset. If the checksum is valid, it can be used. In most cases this will be fine, as the RAM content is never cleared by a reset, it is just not guaranteed to be intact. Note however that if you have a bootloader that runs first, you must make sure that this does not use the same memory region as that would overwrite it during boot. See this thread for details about that.