Skip to content

chipsoft/bt_soc_blinky

Repository files navigation

SoC - Blinky

This example application is the "Hello World" of Bluetooth Low Energy (BLE). It allows a BLE central device to control the LED on the mainboard and receive button press notifications.

Note: this example expects a specific Gecko Bootloader to be present on your device. For details see the Troubleshooting section.

Getting started

To get started with Silicon Labs Bluetooth and Simplicity Studio, see QSG169: Bluetooth SDK v3.x Quick Start Guide.

This example implements a simple custom GATT service with two characteristics. One characteristic controls the state of the LED (ON/OFF) via write operations from a GATT client, and the second characteristic sends notifications to subscribed clients when the button state changes (pressed or released).

To test this demo, install EFR Connect for Android or iOS. Source code for the mobile app is available on Github.

After launching the app go to the demo view and select the Blinky demo. A pop-up will show all the devices around you that are running the SoC-Blinky firmware. Tap on the device to go into the demo view.

Demo view Pop up

Tap the light on the mobile app to toggle the LED on the mainboard. When you press/release the button on the mainboard the state changes for the virtual button on the app as well.

Blinky all off Blinky all on

The animation below showcases the demo running on a BGM220 Explorer Kit (BGM220-EK4314A) with the mobile app running on an Android device.

Radio board power supply switch

Troubleshooting

Bootloader Issues

Note that Example Projects do not include a bootloader. However, Bluetooth-based Example Projects expect a bootloader to be present on the device in order to support device firmware upgrade (DFU). To get your application to work, you should either

  • flash the proper bootloader or
  • remove the DFU functionality from the project.

If you do not wish to add a bootloader, then remove the DFU functionality by uninstalling the Bootloader Application Interface software component -- and all of its dependants. This will automatically put your application code to the start address of the flash, which means that a bootloader is no longer needed, but also that you will not be able to upgrade your firmware.

If you want to add a bootloader, then either

  • Create a bootloader project, build it and flash it to your device. Note that different projects expect different bootloaders:

    • for NCP and RCP projects create a BGAPI UART DFU type bootloader
    • for SoC projects on Series 1 devices create a Bluetooth in-place OTA DFU type bootloader or any Internal Storage type bootloader
    • for SoC projects on Series 2 devices create a Bluetooth Apploader OTA DFU type bootloader
  • or run a precompiled Demo on your device from the Launcher view before flashing your application. Precompiled demos flash both bootloader and application images to the device. Flashing your own application image after the demo will overwrite the demo application but leave the bootloader in place.

    • For NCP and RCP projects, flash the Bluetooth - NCP demo.
    • For SoC projects, flash the Bluetooth - SoC Thermometer demo.

Important Notes:

  • when you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.

  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the -combined.s37 file found in the bootloader project after building the project.

  • On Series 2 devices SoC example projects require a Bluetooth Apploader OTA DFU type bootloader by default. This bootloader needs a lot of flash space and does not fit into the regular bootloader area, hence the application start address must be shifted. This shift is automatically done by the Apploader Support for Applications software component, which is installed by default. If you want to use any other bootloader type, you should remove this software component in order to shift the application start address back to the end of the regular bootloader area. Note, that in this case you cannot do OTA DFU with Apploader, but you can still implement application-level OTA DFU by installing the Application OTA DFU software component instead of In-place OTA DFU.

For more information on bootloaders, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Programming the Radio Board

Before programming the radio board mounted on the mainboard, make sure the power supply switch is in the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

UG103.14: Bluetooth LE Fundamentals

QSG169: Bluetooth SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published