This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Reading back uninitialised variable after soft reset nRF52 GCC

I'm trying to set a global variable in RAM as uninitialised so it can be read back after a soft reset condition:

uint32_t data __attribute__((section("NoInit"), zero_init));

Results in:

warning: 'zero_init' attribute directive ignored [-Wattributes]

Of course it seems this variable is always 0 after reset

Ultimatly I'm trying to create a mechanism to return crash logs over BLE. The idea is that hardfault and APP SDK error variables will be saved into to a global struct before reset. On the next startup, this variable is reported back to the central device.


More Info

According to the gcc_startup_nrf52.S file, the .bss section is cleared if __STARTUP_CLEAR_BSS is defined. My project doesn't define this, so leads me to believe that nothing is cleared on startup. I see that my section call is indeed placing the variable inside a .NoInit section without any extra flags.

The other method I'm trying is to use the RAM Retention example in the SDK where they call SYSTEMOFF after writing to RAM (There doesn't seem to be anything special about this RAM location)

#define RAM_MEMORY_TEST_ADDRESS (0x20002000UL)

uint32_t * volatile p_ram_test = (uint32_t *)RAM_MEMORY_TEST_ADDRESS;

*p_ram_test = RAM_MEMORY_TEST_WORD;

NRF_POWER->SYSTEMOFF = 0x1;

As I'm calling a soft reset the RAM should be fully retained (as specified in the data sheet), so I think this should be the same behaviour. My problem is that the NRF debugger will pin reset the IC on every startup. According to the datasheet, this will clear RAM. I can only use the RTT in this case to print the values. The soft reset makes the RTT loose some data before the reset, but I still see that the values is 0 after power on.

Could my problem be related to the fact that I have a debugger connected that is somehow clearing my RAM?

Parents
  • zero_init isn't a defined GCC attribute so that's why it's ignored. Do you actually have a NoInit section in your linker file and if so what are its attributes. The most likely thing is it's being placed in a section which is zero-erased on startup. You need to go debug the startup code which is called after the reset handler and find out which sections are neither zero-filled, nor loaded from flash.

    @endnode - RAM is not erased on reset. There's no guarantee it doesn't get corrupted but it's not erased. My experience is I've never yet seen it corrupted either but I'm sure it happens.

Reply
  • zero_init isn't a defined GCC attribute so that's why it's ignored. Do you actually have a NoInit section in your linker file and if so what are its attributes. The most likely thing is it's being placed in a section which is zero-erased on startup. You need to go debug the startup code which is called after the reset handler and find out which sections are neither zero-filled, nor loaded from flash.

    @endnode - RAM is not erased on reset. There's no guarantee it doesn't get corrupted but it's not erased. My experience is I've never yet seen it corrupted either but I'm sure it happens.

Children
Related