Getting Started with nrfutil: The Command-Line Tool Every Nordic Developer Needs

Using nrfutil to flash and manage Nordic nRF devices from the command line

You just spent $50 on a Nordic dev kit, tore open the box, plugged it in, and… now you’re staring at 4 different tool names across 6 documentation pages trying to figure out which one actually flashes firmware. nrfjprog? nrfutil? The old nrfutil or the new nrfutil? The pip-installed one or the standalone binary? Nordic’s tooling has gone through a significant overhaul, and if you’re coming from STM32 or ESP32, the confusion is understandable.

By the end of this article, you’ll have nrfutil installed, understand its modular architecture, and know exactly which commands to run to flash and update firmware on nRF54 and nRF52 boards.

What Is nrfutil (and What Changed)?

The old nrfutil (v6.x and earlier) was a Python package you installed via pip. It did one thing well: generate DFU zip packages for the legacy nRF5 SDK.

The new nrfutil (v7.x) is a completely different animal. It’s a native binary, not a Python package, built around a plugin architecture. The base tool is just a lightweight launcher. All the real functionality comes from subcommand packages you install separately.

The key subcommands you’ll care about:

  • device: probe, flash, erase, reset, debug. This is your daily driver.
  • toolchain-manager: install and manage nRF Connect SDK toolchains.
  • nrf5sdk-tools: generate DFU packages for legacy nRF5 SDK projects.
  • trace: capture modem traces on nRF91 series.

One thing worth clarifying: nrfjprog still works and isn’t deprecated. But nrfutil device is the recommended path forward, and it’s the only option that supports some nRF54-specific workflows like SUIT DFU.

Installing nrfutil

Windows

Download the standalone .exe from Nordic’s nrfutil page. Drop it somewhere sensible (like C:\Nordic\nrfutil\) and add that folder to your system PATH.

Open a fresh terminal and verify:

nrfutil --version

macOS

Download the standalone binary for your architecture (Intel or Apple Silicon). Then:

chmod +x nrfutil
sudo mv nrfutil /usr/local/bin/

macOS Gatekeeper will probably block the first run. Head to System Settings > Privacy & Security and click “Allow Anyway.” Run the command again.

Linux

Same drill: download, make executable, move to PATH.

chmod +x nrfutil
sudo mv nrfutil /usr/local/bin/

If your board isn’t detected later, you’ll likely need to add udev rules for SEGGER J-Link. Nordic’s J-Link page has the .rules file.

Install the Subcommands

The base binary can’t do much on its own. Install what you need:

nrfutil install device
nrfutil install toolchain-manager

If you’re working with legacy nRF5 SDK projects (common for nRF52 BLE apps):

nrfutil install nrf5sdk-tools

Verify everything landed correctly:

nrfutil device --help

You should see a list of subcommands including program, erase, reset, and list.

Connecting Your Board

Plug in your DK via USB and run:

nrfutil device list

You’ll get output showing each connected device with its serial number, J-Link probe info, and board type:

004400012345    SEGGER J-LINK    nRF54L15-DK    /dev/ttyACM0

If you see nothing, check three things in this order:

  1. USB cable. Charge-only cables are everywhere. Use one you know carries data.
  2. J-Link drivers. Install or update the SEGGER J-Link software package.
  3. Permissions (Linux). Your user needs access to the USB device. The udev rules fix this, or you can test with sudo as a quick sanity check.

If you’ve got multiple boards plugged in, note the serial numbers. You’ll use --snr <serial_number> to target a specific one.

Flashing Firmware to nRF54 and nRF52

Flashing a .hex File (nRF54L15)

The nRF54L15 flow is the most familiar if you’re coming from nRF52. Build your application (via west build in nRF Connect SDK), then:

nrfutil device program --firmware build/zephyr/zephyr.hex --traits jlink

The --traits jlink flag tells nrfutil to use the onboard J-Link debug probe. For DK boards, you’ll almost always include this.

Flashing a .hex File (nRF54H20)

The nRF54H20 is different. It uses SUIT (Software Updates for Internet of Things) as its update architecture. The board also requires provisioning before your application firmware will run, so there’s a two-stage process: flash the Secure Domain Firmware (SDFW) and System Controller Firmware (SCFW) first, then set the correct lifecycle state.

Don’t skip this. If you flash an application hex and nothing happens, this is almost certainly why. Nordic’s nRF54H20 getting started guide walks through the provisioning sequence.

Once provisioned, SUIT-based updates look like this:

nrfutil device x-suit-dfu --firmware build/zephyr/dfu_suit.suit --traits jlink

Flashing a .hex File (nRF52)

Same command, same tool:

nrfutil device program --firmware build/zephyr/zephyr.hex --traits jlink

If you’ve got multiple boards connected, specify which one:

nrfutil device program --firmware app.hex --traits jlink --snr 682904321

Erasing Before Flashing

Full chip erase:

nrfutil device erase --traits jlink

Or combine erase and flash in one step:

nrfutil device program --firmware app.hex --traits jlink --erase

Resetting the Board 

nrfutil device reset --traits jlink

Useful after flashing, or when you need a clean restart without touching the firmware.

Performing DFU (Device Firmware Update)

Flashing via J-Link is great during development. But in the field (or during testing without a debugger), you need DFU: pushing firmware over USB or BLE.

nRF54H20 DFU via SUIT

SUIT wraps a firmware image in a manifest “envelope” containing metadata, authentication info, and the payload:

nrfutil device x-suit-dfu --firmware envelope.suit --traits jlink

SUIT is a deep topic, well beyond a getting-started article. Nordic’s SUIT documentation covers manifest structure, signing, and multi-image updates.

nRF52 DFU (Legacy nRF5 SDK)

If you’re on the legacy nRF5 SDK (not Zephyr/nRF Connect SDK), you generate a DFU package, then push it:

Generate the zip:

nrfutil nrf5sdk-tools pkg generate \
  --hw-version 52 \
  --sd-req 0x00 \
  --application app.hex \
  --application-version 1 \
  app_dfu.zip

Push via USB serial:

nrfutil nrf5sdk-tools dfu usb-serial --package app_dfu.zip --port COM3

On macOS/Linux, replace COM3 with your serial port (something like /dev/ttyACM0).

Important distinction: nRF Connect SDK (Zephyr-based) on nRF52 uses MCUboot and mcumgr for DFU, not the legacy nrfutil flow. The commands above are only for projects built against the old nRF5 SDK.

If you’re building BLE devices on nRF52 and considering satellite or terrestrial connectivity, Hubble’s firmware SDK for BLE devices works with standard Nordic toolchains, and the Nordic SoftDevice reference application shows a working integration you can flash with the same nrfutil commands covered here.

Essential Commands Cheat Sheet 

Task                              Command
──────────────────────────────    ─────────────────────────────────────────────
List connected devices            nrfutil device list
Flash firmware (.hex)             nrfutil device program --firmware app.hex --traits jlink
Erase chip                        nrfutil device erase --traits jlink
Reset board                       nrfutil device reset --traits jlink
SUIT DFU (nRF54H20)              nrfutil device x-suit-dfu --firmware x.suit --traits jlink
Legacy DFU zip generate (nRF52)  nrfutil nrf5sdk-tools pkg generate ...
Install a subcommand              nrfutil install <package-name>
Update all subcommands            nrfutil self-upgrade && nrfutil upgrade
Check version                     nrfutil --version

Pitfalls That’ll Cost You an Hour

Mixing old and new nrfutil. If you previously pip-installed nrfutil v6.x, it might still be in your PATH. Running nrfutil could invoke the old Python version instead of the new native binary. Check with nrfutil --version; if it says 6.x, uninstall the old one (pip uninstall nrfutil).

nRF54H20 lifecycle state. The nRF54H20 has a hardware lifecycle state machine. A brand-new chip won’t run your application until you provision the secure domain firmware and advance the lifecycle state. The symptoms are maddening: flash succeeds, board does nothing. Read the provisioning docs before you suspect a hardware defect.

Outdated subcommands. nRF54 support is evolving fast. Flags and subcommand names change between releases, so run nrfutil upgrade regularly, especially before filing a bug report. A five-second update can save you an hour of debugging phantom errors.

Multiple boards on one USB hub. nrfutil device program will target whichever board it finds first if you don’t specify. Always pass --snr <serial_number> when more than one board is connected. Grab serial numbers from nrfutil device list.

Next Steps by Project Type

  • Set up nRF Connect SDK using nrfutil toolchain-manager install to pull a specific SDK version. This pairs with west for building Zephyr-based applications.
  • Try VS Code + nRF Connect Extension if you prefer a GUI. It uses the same underlying tools but wraps them in a click-friendly interface.
  • Explore nrfutil device deeper: nrfutil device --help reveals subcommands for reading/writing memory, capturing RTT logs, and more.

For BLE-specific projects, Hubble’s device integration guide covers how to get data flowing from a Nordic BLE device through to the cloud, picking up right where this flashing workflow leaves off.

Hubble Network connects your Nordic BLE devices to the cloud without ground infrastructure. See how it works →