Inquiry on SRAM Retention and Potential Clearing Mechanism on nRF52840

[lancaster]

Dear Nordic Semiconductor Support Team,

I am conducting academic research with the nRF52840 development board, specifically investigating the use of SRAM Physical Unclonable Function (PUF) capabi

During our testing, we noticed that upon power-up, the SRAM contents appear to be completely cleared, with all bits set to zero. This leads us to question whether this behavior is due to a default hardware mechanism in the chip that erases SRAM on power-up or reset.

To clarify this behavior and unde

1. Default Power-Up Behavior: Does the nRF52840 inherently include a hardware-based SRAM clearing or erase process upon power-up or reset? If so, is this behavior configurable, or is it a fixed security feature within the chip that cannot be disabled?

2. Accessing Initial SRAM Pattern: If SRAM clearing is configurable, is there a way to prevent this erase operation so that we can access the SRAM’s natu

3. Impact of Reset Modes: Could different reset methods (such as soft reset versus hard

Please note that this inquiry is solely for academic purposes. Any gui

Thank you very much for your time and help.

Best regards,

Lancaster Liu

[Charlie]

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:

• https://docs.nordicsemi.com/bundle/ps_nrf52840/page/dif.html#d402e184
• (77) Working with the nRF52 Series' improved APPROTECT - Blogs - Nordic Blog - Nordic DevZone

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

[lancaster]

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