Retained register

[AlexManfrex]

Hi,

I need to save a 16 bit counter into a retained register.

I cannot use the 2 GPRETREG since they are already used and I cannot write internal flash.

I cannot use RAM retained.

Is there any other register suitable for this purpose?

[Einar Thorsrud]

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.

[Gmrck]

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.

[Gmrck]

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?

[hmolesworth]

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

[Einar Thorsrud]

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;
}

[Gmrck]

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.

[Einar Thorsrud]

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);

[Gmrck]

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