This KBA going to highlight the main differences between SDK 2.4.x and newer SDK versions and provides a guide about moving existing projects to the SDK 2.7.0.  

SDK 2.4.2 vs SDK 2.6.0

SDK 2.6.0 changed the way of hardware initialization and configuration flow. Additionally, it changed the structure of projects. Let’s go through on these changes one by one.

  • No linked resources from SDK folders. Every .c and .h file copied to the folder of the project. The folder structure is the same as in gecko SDK suit except for emlib and emdrv configuration files are copied to project root.
  • The .hwconf file removed, so there is no graphical way to configure peripherals
  • As the .hwconf file removed the src\InitDevice.c and src\InitDevice.h also removed. These files use to contain peripheral initialization code. This initialization code was called in main.c before gecko_init(). 
void main(void)
  /* Initialize peripherals */

  /* Initialize stack */
  • Introduction of hal-config.h. This file collects the hardware related configuration options.
  • Introduction of init_mcu.c, init_board.c and init_app.c. These files contain MCU, board and application level initialization code. This initialization code now called in main.c before the gecko_init.
void main(void)
  // Initialize device
  // Initialize board
  // Initialize application

  // Initialize stack
  •  Board related initialization code, for example disabling the SPI flash on the radio board, moved from main.c to init_board.c.

SDK 2.6.0 vs SDK 2.7.0

SDK 2.7.0 introduced a new OTA mechanism called Application Loader. This mechanism only works with the latest Gecko Bootloader. Additionally, the stack now provided as a library and not as a binary blob. The list below highlights the most important effects of these changes.

  • Bluetooth stack library moved from

<project -folder>\protocol\bluetooth_2.6\lib\<MCU_family>\EABI\binstack.o


<project -folder>\protocol\bluetooth_2.7\lib\<MCU_family>\<compiler>\libbluetooth.a

  • In SDK 2.7 OTA relies on the application loader. If a project wants to use OTA the application loader object file must be added to the project. The file can be found here:


The file is added to the SoC examples example by default but NCP examples do not contain that as they typically updated by UART DFU.

  • Application loader expects gecko bootloader. The application loader is not supported by legacy bootloaders. In practice if OTA used, then the application loader is mandatory, therefore the gecko bootloader is mandatory too.
  • Since SDK 2.7.0 examples do not contain default bootloader. Therefore, the bootloader must be built and flashed separately using the Gecko Bootloader SDK or with downloading prebuilt demos.

bootloader SDK

  • Because Application Loader introduced and Bluetooth stack now provided as a library, memory layout also changed. This change affects the .ld (GCC) or .icf (IAR) linker script files too.  
  • aat.h removed from main.c because Application Loader does not need that.
  • boards.h removed and its content moved to ble-configuration.h.

Porting Tips

Because these fundamental changes, migration to SDK 2.7.0 from SDK 2.4.2 or older is not a trivial task. Here we collect few tips which may make the process easier.

  • Start your project from soc-empty or ncp-empty example then add your application source and header files from the old project.
  • It is wise to merge the content of the old InitDevice.c to the new init_mcu.c.
  • Don’t use the old main.c because it includes different headers and calls different initialization functions. Copy only the event handling loop to the new main.
  • Don’t use linker script from your old project.
  • Import your old gatt.xml with the visual GATT editor in case you want to modify the GATT in the future. In case you don’t want to update it just copy gatt_db.c and gatt_db.h from the old project. 


  • In case you modified the init_mcu.c, init_board.c or init_app.c make sure you don’t overwrite them in case of generating the GATT.


  • Again: Gecko bootloader is mandatory in case of OTA, you can read more about this here.


  • Knowledge Base Articles
  • Bluetooth Low Energy
  •  Hello, Thanks for the info.

    You must warn users before applying updates that destroy the structure of the project. A huge red banner! We had a deadline yesterday, but Simplicity's "update" made the project completely inoperable. Already spent 20 hours to catch the next errors in the build system.

    Do the backward compatibility mode, do automatic migration scripts, make a short instruction for users before starting the migration. Is someone involved in planning the development of the IDE environment?

    The process of setting up a compilation of even a complex project based on a makefile in the GCC takes a maximum of half a day. You simplified Simplicity so much that the process became unmanageable. We have problems on each issue from the configuration of the pins to the management of the project as a whole, while our other projects of 100 thousand lines are accompanied without problems in the same GCC.

    Problems started with trying to add a button input. The system was updated automatically. Attempts to use SDK 2.4 are also unsuccessful. Probably it will turn out completely to uninstall 2.7.0 and turn off the updates. Some settings in the project have already been changed under SDK 2.7.0 and they will have to be fixed manually.
  • Hi,

    Please find the attached video. We were working with SDK2.6.0. But then in between we uninstall simplicity studio and reinstall it. So now we have only SDK2.7.

    When we flash the device through flash programmer, if we Erase and flash the device, it seems bootloading information is gone. If we flash the device without erasing, the device is working fine and no errors. Details will be clear from the video. Why is this happening?


    We never faced this problem when working with SDKv2.6.

    Thanks & Regards,


  • Hello,

    One more day wasted to make our progect to work. Happy holiday's "SDK 2.7.x"

    The CMU initialization code no more enable peripheral clocks even if module turned to use by Configurator. Great!

    Working old code from InitDevice.c (valued only):

    // CMU_enter_DefaultMode_from_RESET
    extern void CMU_enter_DefaultMode_from_RESET( void )
     // $[Peripheral Clock enables]
     /* Enable clock for GPIO by default */
     CMU_ClockEnable( cmuClock_GPIO, true );
     // [Peripheral Clock enables]$

    New project generated using SDK 2.7.x do not contain GPIO clock enable function. Greeping take a result in function only: int BSP_EbiInit(void) but this function never executed. In our case adding a call CMU_ClockEnable (cmuClock_GPIO, true); switched the port's to work.

    So, if you want to use something, you must to enable the clocking of these modules manually.