Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

about NRF_POWER->GPREGRET & GPREGRET2

I am currently using the NRF_POWER->GPREGRET and GPREGRET2 registers to store data for my custom handling under NVIC_reset. My objective is to identify the cause of a manual reset after the system resets and then execute corresponding operations accordingly. I have the following questions:
  1. Can it be confirmed that these registers will not be manipulated by the protocol stack or other parts of the SDK? I am concerned that in certain scenarios (e.g., crashes caused by protocol stack exceptions), the protocol stack or SDK might overwrite these registers, leading to incorrect program judgments after a reset. I am using the S140 protocol stack + nRF52833, with nRF5 SDK .
    Additionally, I have implemented a bootloader (modified based on the official bootloader) where all operations related to these two registers have been removed, so there is no need to worry about interference from the bootloader. Furthermore, I am not using the official OTA (Over-the-Air) update process.
  2. Will the default value of these registers be 0x00 after a power-off and subsequent power-on?
  3. When using the NVIC_system_reset() function, will the values of these two registers be retained as they were before the reset?
  4. What is the read/write endurance of the NRF_POWER->GPREGRET register? Approximately how many write/erase cycles can it withstand?
  • H,

    Can it be confirmed that these registers will not be manipulated by the protocol stack or other parts of the SDK?

    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.

    Will the default value of these registers be 0x00 after a power-off and subsequent power-on?

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

    When using the NVIC_system_reset() function, will the values of these two registers be retained as they were before the reset?

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

    What is the read/write endurance of the NRF_POWER->GPREGRET register? Approximately how many write/erase cycles can it withstand?

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

Related