nRF54L15 vs nRF52840: What Changes in Power and Architecture and Tooling

Comparing power consumption, architecture, and tooling between Nordic's nRF54L15 and nRF52840 chips

Your nRF52840 design hits 4.6 mA on TX at 0 dBm. The new nRF54L15 datasheet says 3.4 mA for the same job, on a 128 MHz M33, with RRAM instead of flash. Sounds like a free upgrade until you notice there’s no USB peripheral, the GPIO ports got reshuffled, your bootloader’s key provisioning model is different, and OTA from existing field units is off the table because it’s a hardware revision.

Is it worth porting? Here’s a peer-to-peer take on what actually changes, where the wins are real, and what your first day of porting looks like.

The nRF52840 isn’t going anywhere soon. It’s mature, well-stocked, and Nordic still supports it in nRF Connect SDK. The nRF54L15 is the first 54-series part shipping in real volume, and it’s a genuine generational step, with caveats around drop-in compatibility.

nRF54 vs nRF52: what’s actually different

Start with silicon. The nRF54L15 runs a Cortex-M33 at 128 MHz against the nRF52840’s M4F at 64 MHz. Roughly 2x raw throughput before you account for M33 DSP extensions and TrustZone. RAM stays at 256 KB. Non-volatile storage moves from 1 MB of flash to 1.5 MB of RRAM, which is the more interesting change: byte-level writes, no page erase, faster commit. If you’ve ever fought wear-leveling on a settings partition, RRAM is a quiet quality-of-life upgrade.

The radio is still BLE 5.4, but with improved RX sensitivity (around -97 dBm typical) and lower TX current. Peripheral count dropped: fewer SPIM/TWIM/UARTE instances, but each is more capable. The big architectural shift is the new Global RTC (GRTC), which absorbs a lot of what GPIOTE + RTC + TIMER used to do for low-power timing.

And then there’s the obvious omission: no USB peripheral on nRF54L15. If your product enumerates as a USB device, this conversation ends here.

Feature          nRF52840         nRF54L15
---------------  ---------------  ----------------
CPU              M4F @ 64 MHz     M33 @ 128 MHz
Flash/NVM        1 MB Flash       1.5 MB RRAM
RAM              256 KB           256 KB
Security         CC310            TrustZone + CC312
BLE              5.4              5.4 (improved RX)
USB              Yes              No
Package          aQFN73           QFN48 / WLCSP

Power: the numbers that matter

Nordic’s published figures, with caveats:

Mode              nRF52840    nRF54L15    Delta
----------------  ----------  ----------  ------
TX @ 0 dBm        4.6 mA      3.4 mA      -26%
RX                4.6 mA      3.7 mA      -20%
CPU active/MHz    ~50 µA/MHz  ~20 µA/MHz  -60%
System OFF+RAM    0.4 µA      0.5 µA      ~flat

The CPU active/MHz number is the one to scrutinize. Nordic quotes a range that depends on memory access patterns. PPK2 measurements on real workloads tend to land higher than datasheet-best. Treat -60% as best-case and -40% as the figure to plan against.

The standby win is basically a wash. The real gains are in active radio and the M33 finishing work faster, so you spend less wall-clock time out of System OFF. For a sensor that wakes every 10 seconds, advertises, and goes back to sleep, the duty-cycle math favors the 54L15 by a meaningful margin. Coin-cell wearables and energy-harvesting designs benefit most. A mains-powered gateway? You’ll never notice.

If you’re sending periodic BLE advertising packets to the Hubble Network, the active-radio reduction is exactly the workload that scales: TX is the dominant draw, and you’re cutting it by a quarter.

When to migrate vs stay

Be direct with yourself about which row you’re in:

Scenario                              Recommendation
------------------------------------  --------------
Mid-cycle, stable nRF52840 product    Stay
New product, ships 2025+              Migrate
Need USB device                       Stay (no USB on 54L15)
Power-critical wearable               Migrate
Matter/Thread heavy stack             Evaluate (consider 54H)
Security/TrustZone required           Migrate
Long-life field deployment past 2026  Migrate
Tight BOM, < 512 KB firmware          Either (cost-driven)

USB is the cleanest disqualifier. The next question is whether you’re paying porting cost on a product that’s already shipping fine. If your nRF52840 hits its power budget and the BOM works, leave it alone. New revision? Pick the 54L15 for anything shipping past 2026.

Matter/Thread is the awkward case. The 54L15 handles it, but the 54H series (multi-core, more RAM) is the better target if your stack is heavy. Don’t lock in on 54L15 without checking your IPv6 stack footprint.

Toolchain: nRF54 migration starts here

You need nRF Connect SDK v2.6.0 minimum for nRF54L15. v2.7+ is what you actually want, since 2.6 was the introductory release and several peripheral drivers got real fixes after. The legacy nRF5 SDK doesn’t support 54-series at all and won’t. If you’re still on nRF5 SDK on your 52840 product, the migration is two jumps: nRF5 SDK to NCS on 52840 first, then 52840 to 54L15. Don’t try both at once.

Tooling specifics:

  • VS Code with the nRF Connect extension is the supported path. Segger Embedded Studio is deprecated for new work.
  • West workflow is unchanged. west build, west flash, same muscle memory.
  • sysbuild is the default for multi-image builds (app + MCUboot + network core where applicable). If you’ve been hand-rolling child images on 52840, sysbuild replaces that.
  • Device tree: pinctrl syntax tightened up, board files are different, and you’ll spend an afternoon learning the new GRTC bindings.

If your team has a 52840 NCS project already building cleanly with sysbuild, the toolchain side of the port is maybe a day. If you’re coming from nRF5 SDK or custom Makefiles, budget a week.

Peripheral and pin remapping: the actual pain

This is where the porting hours go. GPIO is now grouped as P0, P1, P2 with different pin counts per port than the 52840 (which had P0 with 32 pins and P1 with 16). You can’t take your existing pin assignments and find-replace them. Pull your schematic and remap.

Peripheral instance counts dropped. The 52840 had 4x SPIM, 2x TWIM, 2x UARTE. The 54L15 gives you fewer instances but each is more flexible. Audit your design: if you were using SPIM3 plus three other SPI buses, confirm the 54L15 has enough.

Most of the remap is config, not code, thanks to pinctrl. Before (52840):

&spi1 {
    pinctrl-0 = <&spi1_default>;
    pinctrl-1 = <&spi1_sleep>;
    pinctrl-names = "default", "sleep";
};

&pinctrl {
    spi1_default: spi1_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 14)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 13)>,
                    <NRF_PSEL(SPIM_MISO, 0, 15)>;
        };
    };
};

After (54L15) the structure is the same, the port/pin numbers shift to wherever the 54L15 actually exposes that peripheral on your package:

&pinctrl {
    spi00_default: spi00_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 2, 1)>,
                    <NRF_PSEL(SPIM_MOSI, 2, 2)>,
                    <NRF_PSEL(SPIM_MISO, 2, 4)>;
        };
    };
};

The other one to flag: a lot of GPIOTE-driven timing code on 52840 wants to be GRTC code on 54L15. PPI/DPPI channel routing changed too. If you have a tight ISR-free signal chain (radio event triggers ADC sample, ADC sample triggers DMA), expect to rewrite the channel setup, not just rename macros.

DFU, MCUboot, and the field migration question

MCUboot is still the recommended bootloader, and the high-level OTA flow looks the same from your app’s perspective. Two things changed underneath:

Key provisioning moved to the KMU (Key Management Unit). On 52840 you typically stashed signing keys in UICR or flash. On 54L15, KMU is the supported path, and your provisioning tooling needs to write keys there during manufacturing. Plan a factory-line update.

Slot layout is different because RRAM behaves differently from flash. Run partition manager output through your eyes before first flash. The defaults are sensible, but if you had custom partition sizes on 52840, they won’t transplant. Verify the secondary slot fits your largest expected image plus growth room.

The hard truth on field migration: you can’t OTA from nRF52840 firmware to nRF54L15 firmware. Different silicon, different instruction set extensions, different memory map. Existing units in the field stay on 52840 firmware forever, or you do a physical swap. Plan your SKU strategy accordingly.

Your first 48 hours of porting

If you’re starting a new design in the next six months and don’t need USB, default to nRF54L15. The power numbers are real, the RRAM is a genuine improvement, and you don’t want to ship new hardware on a part that’s already a generation behind.

If you’re mid-cycle on a stable 52840 product, finish the cycle. The migration cost is real (toolchain bump, pin remap, KMU provisioning, partition layout) and there’s no OTA path back to existing units anyway.

Ready to port? Set up nRF Connect SDK v2.7+, get the 54L15 DK on your desk, and build the unmodified blinky sample first to confirm your toolchain. Then pull in your application’s BLE advertising and one peripheral driver (start with the simplest, usually UART). Most of the surprises surface in the first 48 hours of that exercise. The Hubble terrestrial device SDK supports both parts, so the porting work is on the Nordic peripheral and DT layer, not the connectivity side.

Hubble Network’s device SDK runs on both the nRF52840 and nRF54L15, so you can migrate silicon without rewriting your connectivity stack. See how it works →