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.

[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