Why Migrate from nRF5 SDK to nRF Connect SDK?

Many established Nordic products were developed using the nRF5 SDK and have been deployed successfully for years.

However, maintaining an older firmware architecture can become increasingly difficult when a product needs new functionality, newer Nordic devices, modern security features, improved RTOS architecture or a longer-term firmware roadmap.

nRF Connect SDK is a platform that uses Zephyr RTOS as the basis of development and is capable of supporting the latest Nordic wireless developments. Transitioning to this platform can be a good choice to have a more solid base for the following product developments and iterations.

Examples of migration cases include:

  • Transfer of the previous application developed using nRF5 SDK to Zephyr RTOS
  • Support of the new Nordic solutions nRF52/nRF53
  • Updating the old logical architecture of firmware
  • Adding capabilities of BLE, Thread, Zigbee, etc.
  • Improving multitasking and managing peripheral devices
  • Preparing firmware for future OTA and device-management needs
  • Involving new solutions developed by Nordic
  • Reducing the degree of dependence on legacy applications
  • Establishing a codebase that can be maintained for a long time to come.

Migration must be done with care as the change of the SDK and toolchain versions might lead to conflict in compatibility issues. Nordic provides tools for managing SDK/toolchain versions and verifying how all of them relate.

Our nRF5 SDK to NCS Migration Approach

1. Existing Firmware Assessment

We begin by reviewing the existing nRF5 SDK project rather than immediately rewriting the firmware.

Our engineers examine:

  • nRF SoC and board configuration
  • nRF5 SDK version
  • SoftDevice configuration
  • BLE services and profiles
  • GATT and GAP implementation
  • sdk_config.h settings
  • Peripheral drivers
  • Interrupt handling
  • Timers and application scheduling
  • Power-management logic
  • Flash and non-volatile storage
  • Bootloader and DFU implementation
  • External sensors and communication interfaces
  • Custom libraries and third-party dependencies

This assessment helps determine which components can be directly reused, which require adaptation and which should be redesigned using Zephyr-native mechanisms.

2. Planning Migration Framework

Once the existing firmware is understood, we define the target NCS architecture.

Moving legacy software components to Zephyr threads, work queues, timers, drivers, and event interfaces are part and parcel of migration in many cases as well as converting hardware configuration into device tree format while organizing compile configuration in a Kconfig manner.

The Aim here is not to rewrite legacy software line by line. The goal is to keep the needed behavior of the product while creating a simpler architecture that can be maintained and expanded.

3. Peripheral and Driver Migration

Peripheral migration is often one of the most important parts of an nRF5 SDK modernization project.

We can migrate interfaces such as:

  • GPIO
  • UART
  • SPI
  • I²C
  • ADC
  • PWM
  • Timers
  • PDM
  • QSPI
  • USB
  • NFC
  • External flash
  • Sensors
  • Displays
  • Battery-management peripherals

Legacy Nordic drivers and application-specific wrappers are reviewed individually. Where appropriate, functionality is mapped to Zephyr APIs and supported Nordic drivers rather than creating unnecessary custom replacements.

4. Bluetooth Low Energy Migration

BLE is frequently at the center of nRF5 SDK applications. A migration must therefore preserve not only basic advertising and connections but also application-specific behavior.

Our BLE migration work can include:

  • Advertising and scanning
  • GAP configuration
  • GATT services
  • Characteristics and descriptors
  • Notifications and indications
  • Pairing and bonding
  • Security configuration
  • Connection parameters
  • Central/peripheral functionality
  • BLE power optimization
  • Custom BLE protocols
  • Mobile application interoperability

Adequate Infosoft has practical Nordic BLE development experience. Our existing nRF52-powered smart lock project included BLE GATT services, secure pairing, encrypted command processing, motor control, OTA support and a firmware architecture using the Nordic SDK, with Zephyr considered for more advanced versions.

5. RTOS and Application Logic Migration

A legacy nRF5 SDK application may use main-loop processing, Nordic timers, scheduler mechanisms or custom state machines. During migration, these structures can be reorganized into Zephyr's RTOS architecture.

Depending on the application, we may use:

  • Threads
  • Work queues
  • Message queues
  • Semaphores
  • Mutexes
  • Timers
  • Events
  • Interrupt-driven processing
  • Device-driver abstractions

The objective is predictable execution, clear separation of responsibilities and easier future development.

6. Bootloader, DFU and OTA Migration

Firmware updates play a critical role in connected products. Therefore, migration has to be done carefully, taking into consideration the existing bootloader, firmware image design and the update process.

We evaluate the current DFU architecture and select the best approach based on NCS, depending on the product over which the migration is to take place. We also verify:

  • Generation of firmware images
  • Versions management
  • Bootloader performance
  • Updating and rollback needs
  • Bluetooth-based updating
  • Updating in a secure way
  • Flash partitioning process
  • Application compatibility

It can be concluded that the final solution will depend on the type of architecture and update requirements in force.

Relevant Nordic Development Experience

Our Nordic work covers firmware, BLE, embedded systems, PCB design and product prototyping.

Together, these projects demonstrate the engineering capabilities required for a controlled nRF5 SDK-to-NCS migration: understanding existing firmware behavior, mapping proprietary SDK components to Zephyr subsystems, migrating BLE services and drivers, preserving low-power operation, implementing secure DFU, validating hardware behavior, and testing the migrated application on the target Nordic platform.

Power Optimization During Migration

Moving to a new RTOS should not compromise battery life. For battery-operated Nordic devices, we review active current, sleep behavior, peripheral activity, radio configuration and unnecessary wake-ups during migration.

We can profile different operating states and optimize firmware scheduling and peripheral usage.

Adequate Infosoft's Nordic development experience includes low-power wearable and BLE products.

In our nRF52-based smart watch project, the firmware architecture included sensor acquisition, BLE synchronization, secure pairing, power-state management and OTA-ready firmware. The project used nRF52840 and nRF52832 devices for different product configurations.

Hardware and Firmware Validation

Migration is incomplete until the new firmware has been validated on real hardware.

Our engineering workflow can include:

  • Build and compile validation
  • Peripheral-level testing
  • BLE interoperability testing
  • Sensor and interface testing
  • Power-consumption profiling
  • Memory and CPU analysis
  • Stress and long-duration testing
  • OTA/DFU testing
  • Regression testing against legacy firmware
  • Production-oriented hardware validation

Adequate Infosoft also provides Nordic PCB and BLE prototyping services, including current profiling, RF testing and rapid PCB assembly. This allows firmware and hardware considerations to be evaluated together when a migration also involves board revisions.

Why Choose Adequate Infosoft?

Adequate Infosoft combines Nordic firmware development, BLE, embedded hardware, PCB design and IoT engineering capabilities. This matters when migration issues cross the boundary between software and hardware.

During the process of development, our engineers can analyze problems related to BLE behavior, timing of peripherals, consumption of energy, interfaces at the board level, performance of RF and architecture of the firmware.

Our objective is to achieve practical migration results: keeping things under control, reducing unnecessary redevelopment and providing a base NCS/Zephyr infrastructure for future features.

Ashok Patel
Ashok Patel
Senior Engineering Project Manager
AI/ML, DevOps, Data Science & Automation | IoT & C#/.NET | Azure & AWS Expert | Certified AI & Cloud Engineer | 1,500+ LinkedIn Followers
Facebook LinkedIn Stack Overflow