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

[EyalR]

Hi Simon,

Currently 48k out of 64k RAM is used when building the project.
I've attached the RAM breakdown from the build. I'm looking into RAM7 Section 1 which starts at 0x2000F000

When is this heap initialization to 0xCDCDCDCD happening? It persists through reset so it's not just from the initial build.

About what the device does, it has BLE capabilities but specifically in the section I am testing the BLE task isn't running and GAP and such aren't even initialized.

Before going to sleep the device saves an expected wake up reason to GPREGRET. It then goes to sleep and I wake it up by GPIO by pressing a button. The device wakes up, initializes embOS, and then compares the wake up reason from RESETREAS to the one retained in GPREGRET. If it doesn't match then it goes back to sleep. Part of the going to sleep routine is also to retain RAM7 section 1. The device does many other things but this is the current functionality that I'm testing.

About using the example, like I said this is not my code. Someone else wrote it and we've discovered a bug and now I'm trying to reverse engineer it - I don't have the option to start a new project based on an example because this is an existing device.

[EyalR]

I managed to see now that RAM is indeed retained but after the call to OS_InitKern(), which is the very first line of code, the RAM is then initialized to 0xCDCDCDCD. I assume then that this is an embOS related issue. We are using embOS-Safe in our project