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!

[patjshan]

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

[Ligo George]

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.

[patjshan]

Ah I see, thanks for clarifying