Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

Nguyen Hoan Hoang — Sat, 07 Mar 2026 03:23:07 GMT

Hi Ligo,

Thanks for writing this up — we hit the same friction moving an nRF5-SDK monorepo mindset toward nRF54.

Also, thanks Edvin for clarifying the DFU architecture. For anyone following: in NCS BM the transport is handled by the Firmware Loader (using the SoftDevice/BLE stack), while MCUboot is primarily image validation/boot, and the new doc link helps clear up the “where is BLE transport?” question.

On the tooling/monorepo side (West/Kconfig + DT partitions): if your main goal is to keep a “single codebase / bare-metal C/C++ workflow” without adopting Zephyr-style configuration as the primary model, I’ve been building an alternative workflow around Nordic’s nRF54 bare-metal vendor layer (sdk-nrf-bm + nrfx) but with configuration expressed as normal C/C++ structures + a simple pin-map header.

Disclosure: I’m the author of IOcomposer/IOsonata.

Unedited demo (~3 min): AI creates a complete nRF54L15 bare-metal BLE project from a prompt, then it builds and launches debug:
https://youtu.be/LR2vYtMeC8A
Try/install: https://iocomposer.io
Framework (MIT): github.com/.../IOsonata

If you end up trying it, I’d love to hear whether it fits your monorepo workflow (and what breaks first).

— Hoan

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

Ligo George — Fri, 05 Sep 2025 13:14:06 GMT

Thanks for the update. I will try this out.

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

Edvin — Fri, 05 Sep 2025 12:37:00 GMT

This documentation was also just released (since my last reply).

https://docs.nordicsemi.com/bundle/nrf-bm-latest/page/migration/nrf5_bm_migration_5.html#dfu

It explains the differences between the old (nRF5 SDK) bootloader and the new (NCS BM) bootloader.

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

Edvin — Fri, 05 Sep 2025 08:15:26 GMT

Sorry, what I wrote about DFU in my previous reply was incorrect.

The bootloader in NCS BM does use the same bluetooth stack as the application, but seeing as it is a standalone hex file, you can update the application without doing it via the application. That means the bootloader can use the softdevice, and hence, you don't need dual bank, which allows for a larger application footprint.

[quote user="Ligo George"]We’re particularly interested in achieving bootloader-level BLE DFU without relying on application-layer solutions like mcumgr[/quote]

So this is what we currently have in NCS BM, and it is very similar to the nRF5 SDK's bootloader. There are some differences, but from a user perspective it will feel similar. To go a bit more in depth, the bootloader, which is based on mcuboot used in NCS, is now only responsible for validating the images, and start the correct image: Application or Firmware Loader.

The Firmware Loader handles transport of new DFU images. It uses the softdevice to receive the new image. The new image can either contain a new application, or it can contain a softdevice image.

The application image is quite simple, as it contains the new application, and it will just place it directly in it's target destination.

A SoftDevice image is a bit more complex. It is as simple as the application to update for the users, as it is a signed binary file, but it contains the softdevice itself, a new Firmware Loader (compatible with the new SoftDevice, and an installer.

Since the softdevice image is placed in the application's RRAM (NVME), when it is transferred and booted up, it will start the installer, which will delete the old Firmware Loader and the old Softdevice. Then it will move the new Firmware Loader and the new SoftDevice to the correct addresses, before it will delete itself. After this, you have the new softdevice and firmware loader, and it will enter DFU mode again, ready to receive a new application, which is compatible with the new SoftDevice.

I hope that makes things a bit clear, and I want to underline that what I said in the previous reply about it having it's own small BLE stack is incorrect.

You can read about the new bootloader and DFU, and the different components of the bootloader here:

Application Update

SoftDevice and Firmware Loader update

To test this, please see the "building and running". You can skip all the theory above it, as it explains how to create your own board files for a custom board. This is already done for the DK, so just build for the board named bm_nrf54l15dk/nrf54l15/cpuapp/s115_softdevice/mcuboot

And follow the instructions. The bootloader will be built and flashed when you flash this application project (you still need to flash the softdevice separately). The images will also be generated when you build, so to test, change something in the application (add a line of logging), and build it again. In the build folder you will find the zephyr.signed.bin, which contains the application image, and the installer_softdevice_firmware_loader.bin, which contains the new softdevice, firmware loader, and installer image.

We currently only have one softdevice, so there is really no good ways of testing this, but you can transfer the installer_softdevice_firmware_loader.bin, and it will replace the "old" softdevice and firmware loader with the "new" one.

Best regards,

Edvin

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

Ligo George — Thu, 04 Sep 2025 21:20:01 GMT

As for DFU. Actually, the bootloader in NCS BM is not dependent on the application to perform BLE transfers. In fact, it is not even dependent on the softdevice. It has it's own, small, BLE stack. So you can, like you could in the old nRF5 SDK, update the softdevice and application, without dual bank. It is still a bit rough around the edges, but I believe you will have the same capabilities that you did in the nRF5 SDK.

This is encouraging, as it aligns with our need for bootloader-level BLE DFU, similar to what we use in nRF5 SDK. However, I’m a bit confused because the Nordic documentation states that MCUboot does not include transport support (such as BLE) in NCS BM, unlike the nRF5 SDK bootloader. Specifically, the migration guide here notes: "A major difference is that the nRF5 bootloader included the transport (such as BLE, UART), whereas MCUboot does not."

Could you please clarify how BLE DFU is implemented in the NCS BM bootloader? If MCUboot indeed supports BLE transport with its own stack, could you share a link to relevant documentation, a sample project, or a guide that demonstrates how to set this up for nRF54? We’re particularly interested in achieving bootloader-level BLE DFU without relying on application-layer solutions like mcumgr, as we do in nRF5 SDK. Any examples or steps to test this functionality (e.g., updating the SoftDevice and application) would be greatly appreciated.

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

rbence — Thu, 04 Sep 2025 15:36:46 GMT

Hi Edvin,

I don't want to hijack OP's post but do your words about DFU mean that the NCS BM's mcuboot + softdevice + firmware loader could be used as a DFU method with a "really" bare metal application FW(no zephyr stuff, just simple cmake + GCC and the NRFX MDK)? I suppose an image must be created with mcuboot's image tool.

Thank you in advance.

Best regards,
Bence

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

Edvin — Thu, 04 Sep 2025 13:59:15 GMT

Hello, and thank you for your feedback!

Yes, there are differences between the NCS Bare Metal (NCS BM) and the old nRF5 SDK, such as the toolchain and some library changes. And it does depend on some Zephyr features, such as the devicetree. But this is only limited to the partitions, and doesn't require you to use it for enabling peripherals, like you do in the "full" nRF Connect SDK.

I do see your concern with it being difficult to have a shared codebase for both the nRF5SDK and NCS BM. But the idea is that it should be fairly simple to port an application from nRF5 SDK to NCS BM. While I agree it is probably a bit more work than a normal nRF5 SDK port job, it will be far easier in the future to port applications between different nRF54L targets, and any future devices that will be supported in NCS BM. It would simply be a change of the target board. That is one of the big advantages with NCS and NCS BM.

As for DFU. Actually, the bootloader in NCS BM is not dependent on the application to perform BLE transfers. In fact, it is not even dependent on the softdevice. It has it's own, small, BLE stack. So you can, like you could in the old nRF5 SDK, update the softdevice and application, without dual bank. It is still a bit rough around the edges, but I believe you will have the same capabilities that you did in the nRF5 SDK.

Currently, there is only one softdevice, but you can test it by updating to the same softdevice, as described in the application.

Best regards,

Edvin

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

patjshan — Wed, 03 Sep 2025 13:24:20 GMT

Ah I see, thanks for clarifying

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

Ligo George — Wed, 03 Sep 2025 13:08:04 GMT

I want to clarify that my inquiry goes beyond just enabling DFU via BLE within the application.

What I'm referring to is the feature in the nRF5 SDK where the bootloader itself has the inherent capability to perform BLE transfers, without relying on an application layer solution like mcumgr. In the nRF5 SDK, the BLE DFU transport mechanism in the bootloader directly utilizes the SoftDevice.

RE: Challenges Migrating from nRF5 SDK 17 to nRF Connect Bare Metal SDK for nRF54 Integration

patjshan — Wed, 03 Sep 2025 13:04:42 GMT

I'm just getting into the nrf Bare metal sdk myself but I believe it does support DFU over BLE if thats what your referring to in your second point. I was able to get the MCUboot examples working and perform an OTA DFU using the device manager app on iOS.

The other points I agree with, but I see no way around just having to manage a separate repository for your new products. Maybe you could manage it all in one place with a lot of preprocessor defines in your files but that seems like it could get more confusing than the alternative