RE: about NRF_POWER->GPREGRET & GPREGRET2

Einar Thorsrud — Tue, 10 Mar 2026 13:12:00 GMT

[quote user=""]Can it be confirmed that these registers will not be manipulated by the protocol stack or other parts of the SDK?[/quote]

Yes, the protocol stacks like the Bluetooth stack do not utilize GPREGRET. The only exception is the nRF5 SDK Secure Bootloader, which does use GPREGRET as part of the buttonless DFU implementation, where the application sets a magic word in GPREGRET that is read by the bootloader to know it it should enter DFU mode or start the application. See Bootloader documentation.The bootlaoder also use GPREGRET2 to skip CRC check. Both these features can be disabled in the bootloader's sdk_config.h (provided you do not need them), by setting NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 and NRF_BL_DFU_ENTER_METHOD_GPREGRET to 0.

Ass you mave removed this from the bootloader you use, there should be no concerns.

[quote user=""]Will the default value of these registers be 0x00 after a power-off and subsequent power-on?[/quote]

Yes. GPREGRET and GPREGRET2 are reset to 0x00 after a power on reset, and all other reset sources that triggers a reset of GPREGRET.

[quote user=""]When using the NVIC_system_reset() function, will the values of these two registers be retained as they were before the reset?[/quote]

Yes, this is a soft reset, and GPREGRET retains its state during a soft reset. See Reset behavior.

[quote user=""]What is the read/write endurance of the NRF_POWER->GPREGRET register? Approximately how many write/erase cycles can it withstand?[/quote]

GPREGRET is implemented as RAM, so there is no specified or practical limit on write cycles.