nRF54L15 boot strategies from (NVM) RRAM

RE: nRF54L15 boot strategies from (NVM) RRAM

Hieu — Mon, 31 Mar 2025 16:33:12 GMT

I can't comment on every M33 devices, but the nRF54L15 supports execute in place, XiP, which does what you said above. It is explained here: FOTA updates on nRF54L Series devices.

RE: nRF54L15 boot strategies from (NVM) RRAM

dav01 — Sat, 29 Mar 2025 12:17:24 GMT

does the M33 support dynamic memory mapping features to avoid the need for the swap process during an OTA?

RE: nRF54L15 boot strategies from (NVM) RRAM

Hieu — Thu, 23 Jan 2025 20:05:34 GMT

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.

RE: nRF54L15 boot strategies from (NVM) RRAM

dav01 — Thu, 23 Jan 2025 10:56:28 GMT

thanks! so the tools rely on zms and locks regions to prevent bugs in application from overwriting/erasing the RRAM boot areas?

RE: nRF54L15 boot strategies from (NVM) RRAM

Hieu — Thu, 23 Jan 2025 08:38:23 GMT

Hi dav01,

[quote user=""]- are there any implementations available?[/quote]

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.

[quote user=""]- any ways to lock 1st & 2nd-stage bootloader areas to prevent risks of an application overwriting the shared RRAM area runtime!?[/quote]

This is done automatically by the bootloader solution in our nRF Connect SDK (NCS).

Please also see this guide: Developing with nRF54L Series.

Hieu