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]

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

[Gmrck]

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.

[Einar Thorsrud]

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? 

[Gmrck]

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.

[Einar Thorsrud]

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

[Gmrck]

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.

[Einar Thorsrud]

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.

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