Note: BGScript is no longer supported since SDK 2.4.x. We encourage all customers still using BGScript to migrate their applications to C since GCC support was also added in 2.4.x.

This article explains how to use OTA in BGScript applications in the new BLE SDK version 2.0. If you have already tried OTA with earlier versions of the SDK (1.0.x) there are not too many changes that are needed.

1 - Changes needed to the BGScript app

The original BGScript OTA example (for 1.0.x BLE SDK) is available behind this link: http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/BGScript-OTA-example-for-BGM111/ta-p/170665 )

The BGScript example linked above can be ported to SDK 2.0 with just one minimal change. The update image format needs to be changed to use the new format (EBL).

You need to modify the project file *.bgproj as follows:

BEFORE:               <build dfu="ota_proj_1"/>

AFTER:                  <build ebl="ota_proj_1"/>

Replacing 'dfu' with 'ebl' in your <build> configuration is enough, no other changes are needed. The BGScript source code itself can remain untouched.

When you build the project you should see three *.ebl files generated in the project directory:

Repeat the same for the second project ota_proj_2. Note that at the end of this article you can also find a zip file that includes a modified version of the example project where these changes are already done.

Note that the largest file (named *_full.ebl) is not needed for OTA, it is only relevant for UART DFU. 

To try OTA with this example project, first flash your development kit with ota_proj_1. You can later use OTA to update the firmware to ota_proj_2 as explained later in this article.

2 - Building and running the new OTA host app

In BLE SDK 2.0 the OTA host example is found in following directory:

C:\SiliconLabs\SimplicityStudio\v4\developer\stacks\ble\v2.0.0.0\app\bluetooth_2.0\examples_ncp_host\ota_dfu

The project folder contains a Makefile and you can build the host program in e.g. MinGW (by running mingw32-make) or in Cygwin (by running “make”).  After successful compilation, the executable ota-dfu.exe is placed in subfolder named “exe”.

3 – Testing the OTA

Copy the following four *.ebl files to the ota_dfu\exe directory:

ota_proj_1_app.ebl,
ota_proj_1_stack.ebl,
ota_proj_2_app.ebl,
ota_proj_2_stack.ebl

Running the OTA host program is almost same as in previous SDK versions (1.0.x). You need to have a second WSTK connected to your computer and it must be running the “wstk_bgapi” example. The usage of the program is the same, except that you are passing an *.ebl file as input instead of a *.dfu file. See following article for quick introduction if you are not already familiar with the OTA host app:

http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/OTA-DFU-host-example-for-Blue-Gecko/ta-p/171696

Another difference is that stack and application need to be updated separately by running the ota-dfu.exe twice. The previous 1.0.x version also did the update in two parts but the two images (stack and app) were bundled into one large *.dfu file.

Example run #1: using full OTA to update both stack and application.

First run: ./ota-dfu.exe COM49 115200 ota_proj_2_stack.ebl 00:0B:57:0B:49:23

Then run: ./ota-dfu.exe COM49 115200 ota_proj_2_app.ebl 00:0B:57:0B:49:23

The first command will invoke the OTA host program with the new stack image passed as parameter. After updating the stack you will need to run the OTA host program again to update the application. The COM port number and Bluetooth address of the target device need to be obviously changed to match your own test setup.

Below is a screenshot of a full OTA update, run in two phases:

Example run #2: minimal OTA, update only the application

If you want to update only the application you can skip the first part in the above sequence and just run the OTA host application once with the application image given as argument.

In this example, we update application only (ota_proj_2 => ota_proj_1).

./ota-dfu.exe COM49 115200 ota_proj_1_app.ebl 00:0B:57:0B:49:23

4 - How to check if it works?

Both test projects will print some status info via UART. If you have terminal connection open you can easily see if the application has changed. The application version will be printed immediately after boot, for example:

                OTA example, app #1

The device name that is advertised is also dependent on the application. It is either “Ota app #1” or “Ota app #2”.

App #1 blinks the two LEDs in an alternating sequence. App #2 uses the same GPIO pins as inputs (PB0, PB1).