RAM retention failure

RE: RAM retention failure

Pero Krivic — Wed, 16 Mar 2022 11:32:26 GMT

Awesome! Thanks Vidar!

RE: RAM retention failure

Vidar Berg — Wed, 16 Mar 2022 11:28:00 GMT

The linker starts with the first sections and sequentially works its way up one section at a time. So the start address of a section is usually dependent on the size of previous sections. You may, for instance, notice that .non_init gets shifted up when you add more static zero initialized variables in your code (placed in .bss)

SES generates the actual linker script from the flash_placement.xml file. The generated linker script can be found together with the other output files.

RE: RAM retention failure

Pero Krivic — Wed, 16 Mar 2022 11:14:16 GMT

Cool. One last question: in short words, how does the compiler (linker?) determine the addresses of all those sections? I always though it was pregiven in the .ld file (though I never bothered to look it up there)

RE: RAM retention failure

Vidar Berg — Wed, 16 Mar 2022 11:08:32 GMT

Yes, you can specify a fixed start address for the non_init section in your flash_placemecement.xml file.

e.g.

Note that this fixed address must be somewhere between .tbss and .heap (or .stack if you don't use heap).

RE: RAM retention failure

Pero Krivic — Wed, 16 Mar 2022 08:07:01 GMT

[quote userid="4240" url="~/f/nordic-q-a/85770/ram-retention-failure/358338#358338"]You can see where the .non_init section is located in RAM from the memory usage view in SES here (or from the *.map output):[/quote]

Can you believe, I did exaxtly that last night? I found out that my variable lives at 0x20003F00, i.e in the section RAM 1. When I turned off all sections except that one, it worked just fine! How cool is that?

Important: the .non_init section does not start at a fixed address. So it may change between builds. E.g. when you turn off or enable compiler optimization.

This is what I also noticed. Is there a way to fix a variable at the given section and make sure it stays there every time?

RE: RAM retention failure

Vidar Berg — Wed, 16 Mar 2022 07:54:43 GMT

Excellent 🙂

[quote userid="74012" url="~/f/nordic-q-a/85770/ram-retention-failure/358294#358294"]Is that a right way to do things here? Check the variable in RAM, and turn the BLE depending on it?[/quote]

Yes, this will work.

[quote userid="74012" url="~/f/nordic-q-a/85770/ram-retention-failure/358294#358294"] Can you tell me how to find out where my variable actually is, and how to pick a proper RAM region accordingly?[/quote]

You can see where the .non_init section is located in RAM from the memory usage view in SES here (or from the *.map output):

And when you know the address, you can look up the which RAM slave and section it belongs to by referring to figure 1 in the Memory chapter of the PS. Each 4K section consumes about 30 nA when retention is enabled.

Important: the .non_init section does not start at a fixed address. So it may change between builds. E.g. when you turn off or enable compiler optimization.

RE: RAM retention failure

Pero Krivic — Tue, 15 Mar 2022 18:54:01 GMT

Hey Vidar, this has worked out! Thanks man, you're awesome!

I've taken your approach with NRF_POWER->RAM[i].POWERSET functions, since I turn SoftDevice on, only after the RAM retention is set, and only if the variable retained in RAM checks out. Is that a right way to do things here? Check the variable in RAM, and turn the BLE depending on it?

Second, I feel it's kinda waste of power to turn on all of the RAM regions, since my 4-byte variable resides only in one of them. Can you tell me how to find out where my variable actually is, and how to pick a proper RAM region accordingly?

Best,

RE: RAM retention failure

Vidar Berg — Tue, 15 Mar 2022 08:22:58 GMT

Hello,

Thanks for uploading the project. That made it easy to test here. The problem was that you used the sd_power_ram_power_set() function before the Softdevice was enabled so the function was just returning NRF_ERROR_SOFTDEVICE_NOT_ENABLED without actually configuring the power register.

Peripheral view of the POWER module when running your original code:

Notice that the retention bits are set to '0'.

You can access the POWER registers directly as long as the softdevice is disabled. E.g.

      NRF_POWER->RAM[i].POWERSET = ((POWER_RAM_POWER_S0POWER_On << POWER_RAM_POWER_S0POWER_Pos) |
                                   (POWER_RAM_POWER_S1POWER_On << POWER_RAM_POWER_S1POWER_Pos) |
                                   (POWER_RAM_POWER_S0RETENTION_On << POWER_RAM_POWER_S0RETENTION_Pos) |
                                   (POWER_RAM_POWER_S1RETENTION_On << POWER_RAM_POWER_S1RETENTION_Pos));

Best regards,

Vidar

RE: RAM retention failure

Pero Krivic — Mon, 14 Mar 2022 19:09:43 GMT

Hello Vidor, thanks for the reply. I'm not using the bootloader, as far as I know. I have started from ble_app_uart and built upon it, never including any bootloader.

Hey, if it helps, I have uploaded you a complete project - I've stripped down all functionality except ble-uart and ram retention to demonstrate the issue. It should run on PCA10040:

devzone.nordicsemi.com/.../MERS.zip

Best, P

RE: RAM retention failure

Vidar Berg — Mon, 14 Mar 2022 17:01:26 GMT

Hello,

The RAM configuration looks to be correct. However, when the noinit section gets corrupted it usually is because there is a bootloader overwriting the section on startup. Could that be the case here? If not, I will try to set up a test tomorrow and see if I can replicate the issue on my side.

Best regards,

Vidar