Trying to find some docs on "flashing" vs. booting the nRF54L15 from RRAM.
- are there any implementations available?
- any ways to lock 1st & 2nd-stage bootloader areas to prevent risks of an application overwriting the shared RRAM area runtime!?
Trying to find some docs on "flashing" vs. booting the nRF54L15 from RRAM.
- are there any implementations available?
- any ways to lock 1st & 2nd-stage bootloader areas to prevent risks of an application overwriting the shared RRAM area runtime!?
Hi dav01,
- are there any implementations available?
The RRAM is the only non-volatile memory available on the nRF54 Series. Programming and booting are fully implemented. The tools and drivers are setup to be used virtually the same way as with our nRF52 and nRF53 devices.
The only caveat I can think of is that most of the forum discussions on non-volatile application data storage point to using the Non-Volatile Storage solution (NVS). This service integrates some wear-leveling necessary for Flash memory, but irrelevant for RRAM. For the nRF54 Series, use the Zephyr Memory Storage (ZMS) instead.
- any ways to lock 1st & 2nd-stage bootloader areas to prevent risks of an application overwriting the shared RRAM area runtime!?
This is done automatically by the bootloader solution in our nRF Connect SDK (NCS).
Please also see this guide: Developing with nRF54L Series.
Hieu
thanks! so the tools rely on zms and locks regions to prevent bugs in application from overwriting/erasing the RRAM boot areas?
Perhaps my mentioning of ZMS was premature and caused confusion. ZMS is a firmware library that allows the firmware application to store and retrieve data in NVM. It isn't involved in programming and probably is never involved in code execution.
Programming it is done via the Debug and trace system. On our nRF54L15 DK for example, there is an onboard debugger that connect to the access port to perform programming and debugging.
The access restriction of memory regions is also not related to ZMS. The bootloader does so during booting by configuring the Memory Privilege Controller.
In case it isn't clear, RRAM and RAM are two different memories on the nRF54L15. RAM is still Random Access Memory where the heap and stack stays. RRAM is a non-volatile memory, used similar to how flash was used in prior years in most MCUs. Please refer to this document for more details: Memory.
Perhaps my mentioning of ZMS was premature and caused confusion. ZMS is a firmware library that allows the firmware application to store and retrieve data in NVM. It isn't involved in programming and probably is never involved in code execution.
Programming it is done via the Debug and trace system. On our nRF54L15 DK for example, there is an onboard debugger that connect to the access port to perform programming and debugging.
The access restriction of memory regions is also not related to ZMS. The bootloader does so during booting by configuring the Memory Privilege Controller.
In case it isn't clear, RRAM and RAM are two different memories on the nRF54L15. RAM is still Random Access Memory where the heap and stack stays. RRAM is a non-volatile memory, used similar to how flash was used in prior years in most MCUs. Please refer to this document for more details: Memory.