Bluetooth Knowledge Base

Migration guide to Bluetooth SDK 2.7.x

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().

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.

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.

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.

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.

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?

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.

The SDK version on my PC recently changed from 2.6 to 2.7. Unfortunately I wasn't aware that generating a new GATT database would result in the clearing of the functions in init_app.c and init_board.c.

Surprisingly, my project still works, but I have realized that cannot use flow control on the UART connection between host and target anymore.

I want to retrieve the hardware flow control. For this purpose, I tried manually copying and pasting the missing init functions from a given example project. But the compiler complains about several undeclared variables - even though they are declared. How come the compiler gives an error when the variable is clearly declared in the mentioned header file and this header file appears in the includes? I checked that the settings under project->properties->paths and symbols are the same as the settings in the example project, so I can exclude that as the cause for the build error.