RAM Retention Troubleshooting

[EyalR]

Hello,

I was given an existing code with a possible bug in it relating to RAM retention and I'm trying to make sense of what I'm seeing. I am using NRF52832 with SDK 17.0.1 and SoftDevice S112.

In the code, before entering system OFF mode, a request is made to retain RAM[7] section 1:

        sd_power_ram_power_set(7, POWER_RAM_POWERSET_S1RETENTION_Msk);
        ret_code_t err_code = sd_power_system_off();
        LOG_PRINT_ERROR("sd_power_system_off : ERROR %s ", nrf_strerror_get(err_code));

On wakeup (say from NFC), a certain address in RAM is then checked:

uint32_t * volatile p_ram_register = (uint32_t *)(0x2000F000UL);

The contents of this register seems to be always 0xCDCDCDCD.

Things I've tried to figure the code out:

• sd_power_ram_power_set returns success.
• If I try to write a value to the contents of *p_ram_register the program crashes.
• If I write a value to ((uint8_t *)p_ram_register + 1), then everything is fine and if I immediately print the contents of *p_ram_register I can see the altered bytes.
• After wakeup from NFC the contents of *p_ram_register  return to be 0xCDCDCDCD even after writing a different value to 0x2000F001. This is true for other addresses in this RAM section.

Note: According to the linker map the stack starts at 0x0002F000 although I'm not sure how or if that affects RAM retention.

Also I'm currently running with no bootloader although it is an option.

My questions:

1. Why is writing to 0x2000F000 results in program fail but writing to 0x2000F001 is fine?
2. Why isn't the data in section 1 of RAM[7] retaining its value?
3. The datasheet of NRF52832 claims that: The RAM is never reset, but depending on reset source, RAM content may be corrupted. So how is it I get the exact same 0xCDCDCDCD on every run right at the beginning?

Any help would be appreciated 

[Simonr]

Hi

When building your application, how much RAM does the application itself take? I think somewhere in your application you have reserved the area you're trying to write to. 0xCDCDCDCD is used by C/C++ malloc() to mark uninitialized heap memory, so that could be a point in the right direction. Have you used the RAM retention example project in the SDK for reference or are you implementing the RAM retention "free hand"? https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/ram_retention_example.html 

I'd strongly suggest you refer to the RAM retention sample, and then trying to implement it step by step and see at what point it crashes. What else than RAM retention does your project do? I assume you do some radio operations as well since you are using the SoftDevice.

Best regards,

Simon