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

[Ligo George]

We are working to add support for the new nRF54 chips using the nRF Connect Bare Metal SDK within our existing mono-repo, which currently supports multiple product generations using the nRF5 SDK (versions 15 and 17).

Our expectation was that the Bare Metal SDK would integrate smoothly into our codebase, similar to our current setup, allowing us to support nRF54-based products with minimal changes. However, after exploring the new SDK, we’ve encountered significant challenges that make integration more complex than anticipated.

Here are the main issues we’re facing:

1. Toolchain and Configuration Differences: The new SDK relies on a completely different toolchain, including tools like Zephyr West for building and Kconfig for SDK configurations. This is a major shift from the nRF5 SDK workflow. Additionally, memory partitioning now requires Device Tree overlays, which adds complexity to our setup.
2. Bootloader Limitations: The MCUboot bootloader in the Bare Metal SDK lacks BLE transport support, which we heavily rely on as a fallback mechanism in all our current products. This is a critical feature for us, and its absence poses a significant roadblock.
3. Library and API Changes: There are numerous library updates, such as the replacement of app_timer with bm_timer, among others. These changes necessitate widespread code modifications across our codebase.

Our mono-repo approach has worked well for maintaining consistency across product lines, but integrating the nRF Connect Bare Metal SDK in a similar manner seems challenging due to these differences. We're aiming to adopt the nRF54 chips with minimal effort, but the current migration path looks like it will require substantial time and resources.

Any advice or suggestions would be greatly appreciated!

[Nguyen Hoan Hoang]

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