Nordic Launches nRF54L15, nRF54L10, and nRF54L05 as the Successors to nRF52

Nordic Launches nRF54L15, nRF54L10, and nRF54L05 as the Successors to nRF52

Nordic Semiconductor launched the nRF54L15, nRF54L10, and nRF54L05 on November 12, 2024, giving its next-generation wireless architecture a mainstream family aimed at succeeding the widely used nRF52 series. All three combine a 128MHz Arm Cortex-M33, a low-power RISC-V coprocessor, a 2.4GHz radio, and modern security in one system-on-chip.

The devices scale mainly through memory. The nRF54L15 provides 1.5MB of nonvolatile memory and 256KB of RAM. The nRF54L10 has 1MB and 192KB, while the nRF54L05 has 512KB and 96KB. That range lets a design choose capacity without abandoning the family.

Nordic targeted everything from smart rings and game controllers to tags, electronic shelf labels, medical devices, smart homes, and industrial sensors. The nRF54L15 development kit was available at launch, with volume production planned toward the end of 2024.

Why the nRF52 successor matters

The nRF52 series became a default choice for many Bluetooth Low Energy products because it combined a capable radio, approachable development tools, and enough processing for complete applications. Replacing such a platform is more than increasing clock speed. Developers expect software continuity, predictable radio behavior, package options, and years of supply.

Nordic described the nRF54L series as offering twice the processing performance and three times the processing efficiency of comparable nRF52 devices. Vendor benchmark claims should be treated as directional until measured with the intended firmware. Even so, a 128MHz Cortex-M33 provides considerably more headroom than common nRF52 configurations.

More headroom can support richer user interfaces, sensor fusion, security, and multiple protocol stacks. It can also shorten active time, letting the processor return to sleep sooner. Faster is not automatically lower power; clock configuration, peripherals, radio duty cycle, and software efficiency decide the result.

Three memory sizes cover different products

The nRF54L15 is the safest starting point for development because its larger memory leaves room for logging, over-the-air updates, and changing requirements. The smaller parts become attractive when firmware is stable and unit cost or package size dominates.

Memory planning must include more than the application. Bluetooth, Thread, Zigbee, Matter, bootloaders, secure storage, diagnostic logs, and update slots all consume nonvolatile space. RAM holds stacks, heaps, network buffers, and sensor data. A firmware image that barely fits at launch leaves little room for maintenance.

The 6-by-6 QFN (quad flat no-leads, a small square chip package with flat metal pads on the underside instead of protruding pins) package options are pin compatible across the series, giving manufacturers a potential upgrade and cost-down path. Pin compatibility does not guarantee a drop-in software change. Confirm memory map, peripherals, radio configuration, and orderable package details for each part.

A 2.4-by-2.2mm wafer-level chip-scale package offers the smallest option, which Nordic said was 50 percent smaller than the comparable nRF52840 package. Such packages demand fine-pitch assembly, careful escape routing, and manufacturing partners comfortable with inspection and rework.

The RISC-V coprocessor handles low-power work

Each device includes a low-power RISC-V coprocessor. RISC-V (an open, royalty-free instruction set architecture, meaning the basic vocabulary of commands a processor understands) lets any chipmaker build compatible cores without paying licensing fees. A coprocessor can run selected tasks without waking the main Cortex-M33, reducing energy for periodic or timing-sensitive operations.

The practical value depends on the software model. Developers need to know which peripherals and memory the coprocessor can access, how code is built, and how it communicates with the main processor. A small independent task engine can be excellent for sensor polling or housekeeping, but debugging interactions between processors takes discipline.

Start by measuring a simple use case both ways. If moving work to the coprocessor adds synchronization overhead or keeps shared resources powered, the theoretical saving may shrink. Nordic's examples and power tools are the appropriate baseline.

Multiprotocol remains central

The family supports Bluetooth LE, Bluetooth Mesh, Thread, Matter, Zigbee, Amazon Sidewalk, and proprietary 2.4GHz protocols. Nordic also specified proprietary data rates up to 4Mbps and future Bluetooth 6 support, including Channel Sounding.

Multiprotocol does not mean every protocol runs together without limits. Radios share airtime, and protocol stacks compete for memory and processor time. A Matter-over-Thread product may also use Bluetooth for commissioning, which is a planned combination. Adding another continuous proprietary link requires careful scheduling.

Thread supplies the low-power IPv6 mesh used by many Matter devices. Zigbee uses the same 2.4GHz band but a different stack. Bluetooth Mesh serves managed many-to-many Bluetooth networks. Select the protocol based on the complete ecosystem and gateway requirements, not only radio range.

Security moves with the new generation

The nRF54L devices include Arm TrustZone isolation, tamper sensors, and hardened cryptographic accelerators. TrustZone separates secure and nonsecure software regions on the Cortex-M33, helping protect keys and critical services from ordinary application code.

Secure hardware is a foundation, not an automatic result. Products need a signed boot chain, protected update keys, rollback policy, unique device credentials, vulnerability response, and a way to recover from interrupted updates. Matter products also carry ecosystem-specific commissioning and certificate requirements.

The advantage of hardware acceleration is that strong cryptography can consume less time and energy. The advantage of isolation is that a bug in a user-facing feature does not have to expose every secret. Both benefits depend on correct configuration.

Moving an nRF52 design requires testing

The family is a successor, but it is not binary-compatible with an nRF52. New silicon, peripherals, SDK (software development kit) support, packages, and power behavior require a migration project.

Inventory current dependencies first: SoftDevice or controller version, real-time operating system, bootloader, device drivers, radio timing, external flash, and production programming. Port an SDK example to the nRF54L15 DK before moving the application. Then test wireless interoperability, updates, sleep current, and worst-case memory.

Hardware teams should validate the reference antenna layout, power rails, debug access, crystals, and high-frequency routing. A radio board that worked with an nRF52840 should not be copied blindly around a different package.

For new projects, the nRF54L family offers a clearer choice. Use the L15 when requirements are uncertain or software is large, the L10 for a balanced design, and the L05 when a measured application fits comfortably. Leave margin in every case.

The launch supplied the mainstream half of Nordic's fourth generation. Where the nRF54H20 pursued maximum capability, the nRF54L series addresses the broad product range that made nRF52 successful. Its real achievement is not one dramatic feature, but a scalable combination of faster processing, lower-power architecture, modern security, and multiprotocol radio support.

If you're coming from nRF52, I'd port a single SDK example to the nRF54L15 kit first and measure sleep current before touching your real design.

Sources and image credits

Add new comment

Restricted HTML

  • You can align images (data-align="center"), but also videos, blockquotes, and so on.
  • You can caption images (data-caption="Text"), but also videos, blockquotes, and so on.