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!

[Edvin]

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

[rbence]

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