Inquiry on SRAM Retention and Potential Clearing Mechanism on nRF52840

RE: Inquiry on SRAM Retention and Potential Clearing Mechanism on nRF52840

Charlie — Wed, 13 Nov 2024 13:41:26 GMT

Hi Yuxuan,

Thank you for your explanation. I now have a better understanding after your detailed explanation and reading through this Wikipedia article on Types of Physical Unclonable Functions.

According to the nRF52840 datasheet, there is no automatic hardware mechanism for clearing SRAM during power-on. However, on the firmware side, it depends on the SDK being used.

Currently, we have two SDKs for firmware development: the nRF Connect SDK and the nRF5 SDK. We encourage developers to use the newer nRF Connect SDK for new development projects, as it is based on the open-source Zephyr project.

If your firmware is developed using the nRF Connect SDK/Zephyr, memory behavior can also depend on whether a bootloader is used. For bare-metal firmware, the v2.7.0\zephyr\kernel\init.c file includes the z_bss_zero function for zero-initializing RAM, but you can configure this behavior by setting CONFIG_SKIP_BSS_CLEAR to avoid clearing it.

If a bootloader like MCUboot is used, memory initialization settings can vary. I checked MCUboot documentation and code, and it does not explicitly perform zero-initialization of memory regions.

When no firmware is programmed, you should be able to perform SRAM PUF without interference from the firmware, and you can then compare the results when firmware is present.

Hope this will help you a bit for your research. Let me know if you need more help.

Best regards,

Charlie

RE: Inquiry on SRAM Retention and Potential Clearing Mechanism on nRF52840

lancaster — Tue, 12 Nov 2024 11:56:07 GMT

Hi Charlie,

Thank you for your detailed response and for clarifying the behavior of SRAM. I realize that my previous question might have led to some misunderstanding, so I’d like to clarify my intentions more precisely.

I am aware that SRAM, as a volatile memory, loses its data when power is removed. However, my interest lies specifically in capturing the initial, random state of the SRAM immediately upon power-up. This randomness at power-on is crucial for our SRAM PUF (Physical Unclonable Function) implementation. The PUF concept leverages the natural, unique variations in SRAM's power-on state to generate a unique hardware fingerprint for each device.

To be clear, my goal is to access the SRAM’s state right at the moment it is powered up, before any kind of clearing or erasing might take place. I would like to confirm if the nRF52840 incorporates any automatic hardware or firmware-based mechanism that clears the SRAM content immediately after power-up, prior to any code execution. If such a mechanism exists, is there any way to disable it to allow us to observe the unaltered power-on state of the SRAM?

Thank you once again for your assistance, and I look forward to any insights or guidance you can provide on this matter for our research.

Best regards,
Yuxuan

RE: Inquiry on SRAM Retention and Potential Clearing Mechanism on nRF52840

Charlie — Tue, 12 Nov 2024 11:36:29 GMT

Hi Yuxuan,

Thank you for reaching out with your questions. It sounds like a very interesting project, and we're more than happy to assist as much as we can. I noticed that you also have another private ticket with similar questions. To maintain consistency and benefit others who may be interested, I'll answer your questions in this open ticket only. However, if you have any concerns, I can set this thread to private upon request.

Regarding your observation about the SRAM clearing or erase process upon power-up or reset: as far as I know, this behavior is how SRAM works. Being a volatile memory type, SRAM loses its data when power is removed. On the oppsite, If developer want to retain some data in SRAM to enable quicker wake-up and operation, they need consider a tradeoff in power consumption to ensure data retention.

If you’re attempting to access SRAM after code execution has started and data is loading from ROM, keep in mind that the APPROTECT feature is designed to prevent unauthorized memory reads. You can refer to the following resources for details on unlocking memory access when needed:

Additionally, some courses from the Nordic DevAcademy may help you gain a better understanding of the IDE and coding aspects. Feel free to explore those resources as well.

nRF Connect SDK Fundamentals - Nordic Developer Academy

nRF Connect SDK Intermediate - Nordic Developer Academy

Best regards,

Charlie