Introduction

Silicon Labs Wireless Gecko Products offer user-friendly software timers that are suitable for most of the tasks. Despite well performing software timers there are tasks that require hardware timers. Hardware timers offer faster response time than software timers and thus they suit well for example Pulse-width modulation (PWM). This Knowledge Base article explains how to create a simple application that makes use of PWM functionality. Example application includes BLE service that is used to control the PWM functionality remotely.

Implementation

1. Creating the project.

• In Simplicity Studio, create SOC – Empty example project for your device.

• Import the attached gatt.xml file and generate. Open the .isc file, click on custom BLE GATT and click import from the tools section on the right. This will overwrite the existing GATT. Click generate button on the top and accept any pop-ups. We have changed the name of the device to PWM_Example and created a characteristic to control the behavior of the on-board LEDs as shown here.

New service and characteristic

Light_PWM_Control service

Control Characteristic

2. Overwrite the attached app.c in the project folder. In app.c, we have included Timer and GPIO libraries. These libraries are required for PWM signal.

#include "em_timer.h"
#include "em_gpio.h"
#include "em_cmu.h"
// this PWM_FREQ = 65000 creates about 1kHz signal. 
#define PWM_FREQ 65000

3. Hardware timer uses the High Frequency oscillator which will be disabled in the sleep mode. To ensure that timer works, make sure that sleep is disabled. Disable sleep by setting DISABLE_SLEEP to 1 in app.h

/* Set this value to 1 if you want to disable deep sleep completely */
#define DISABLE_SLEEP 1

4. We initialize pins and enable clocks. In the example, WSTK LEDs are used.

/* Enable clock for GPIO module */
  CMU_ClockEnable(cmuClock_GPIO, true);
​
  /* Enable clock for TIMER0 module */
  CMU_ClockEnable(cmuClock_TIMER0, true);
​
  /* Initialize pins used for PWM */
  GPIO_PinModeSet(BSP_GPIO_LED0_PORT, BSP_GPIO_LED0_PIN, gpioModePushPull, 0);
  GPIO_PinModeSet(BSP_GPIO_LED1_PORT, BSP_GPIO_LED1_PIN, gpioModePushPull, 0);

5. Then we route timer channels to LED pins.

• Keep in mind that routing pins are board dependent. For different platforms, the LOC30 parameter may differ. Please refer to the datasheet of your platform for details. This information can be found under "Alternate functionality overview" section of the datasheet. Look for rows starting with TIM0_CC0 and TIM0_CC1. Check the number associated with the LED port and pin. For example in BG1, port PF6 and PF7 are associated with number 30 and 30 respectively in timers TIM0_CC0 and TIM0_CC1.

    /* Route pins to timer */
    // $[TIMER0 I/O setup]
    /* Set up CC0 */
    TIMER0->ROUTELOC0 = (TIMER0->ROUTELOC0 & (~_TIMER_ROUTELOC0_CC0LOC_MASK))
            | TIMER_ROUTELOC0_CC0LOC_LOC30;
    TIMER0->ROUTEPEN = TIMER0->ROUTEPEN | TIMER_ROUTEPEN_CC0PEN;
    /* Set up CC1 */
    TIMER0->ROUTELOC0 = (TIMER0->ROUTELOC0 & (~_TIMER_ROUTELOC0_CC1LOC_MASK))
            | TIMER_ROUTELOC0_CC1LOC_LOC30;
    TIMER0->ROUTEPEN = TIMER0->ROUTEPEN | TIMER_ROUTEPEN_CC1PEN;
    // [TIMER0 I/O setup]$

6. The timer properties and initializing is done in this section.

/* Select CC channel parameters */
  TIMER_InitCC_TypeDef timerCCInit =
  {
    .eventCtrl  = timerEventEveryEdge,
    .edge       = timerEdgeBoth,
    .prsSel     = timerPRSSELCh0,
    .cufoa      = timerOutputActionNone,
    .cofoa      = timerOutputActionNone,
    .cmoa       = timerOutputActionToggle,
    .mode       = timerCCModePWM,
    .filter     = false,
    .prsInput   = false,
    .coist      = false,
    .outInvert  = false,
  };
​
  /* Configure CC channel 0 */
  TIMER_InitCC(TIMER0, 0, &timerCCInit);
​
  /* Configure CC channel 1 */
  TIMER_InitCC(TIMER0, 1, &timerCCInit);
​
  /* Set Top Value */
  TIMER_TopSet(TIMER0, CMU_ClockFreqGet(cmuClock_HFPER)/PWM_FREQ);
​
  /* Set compare value starting at 0 - it will be incremented in the interrupt handler */
  TIMER_CompareBufSet(TIMER0, 0, 0);
​
  /* Set compare value starting at top value - it will be decremented in the interrupt handler */
  TIMER_CompareBufSet(TIMER0, 1, TIMER_TopGet(TIMER0));
​
  /* Select timer parameters */
  TIMER_Init_TypeDef timerInit =
  {
    .enable     = true,
    .debugRun   = true,
    .prescale   = timerPrescale64,
    .clkSel     = timerClkSelHFPerClk,
    .fallAction = timerInputActionNone,
    .riseAction = timerInputActionNone,
    .mode       = timerModeUp,
    .dmaClrAct  = false,
    .quadModeX4 = false,
    .oneShot    = false,
    .sync       = false,
  };
​
  /* Enable overflow interrupt */
  TIMER_IntEnable(TIMER0, TIMER_IF_OF);
​
  /* Enable TIMER0 interrupt vector in NVIC */
  NVIC_EnableIRQ(TIMER0_IRQn);
​
  /* Configure timer */
  TIMER_Init(TIMER0, &timerInit);

7. For the handler function in this example, there is PWM function which has dimming and breathing modes, depending on pwm_mode parameter (0-100 dimming and 101-255 constant breathing).

/* Define PWM mode. The light is constantly changing or staying constant. Value 1-100 defines constant
brightness and the value define duty-cycle. Values 101-255 sets light to constantly changing brightness
which makes breathing effect. */
uint16_t pwm_mode = 200;
​
​
/**************************************************************************//**
 * @brief TIMER0_IRQHandler
 * Interrupt Service Routine TIMER0 Interrupt Line
 * This function is used to configures PWM modes. 
 *****************************************************************************/
void TIMER0_IRQHandler(void)
{
  uint32_t compareValue;
​
  /* Clear flag for TIMER0 overflow interrupt */
  TIMER_IntClear(TIMER0, TIMER_IF_OF);
​
  compareValue = TIMER_CaptureGet(TIMER0, 0);
​
  if (pwm_mode > 100){
​
  /* increment duty-cycle or reset if reached TOP value */
  if( compareValue == TIMER_TopGet(TIMER0))
    TIMER_CompareBufSet(TIMER0, 0, 0);
  else
    TIMER_CompareBufSet(TIMER0, 0, ++compareValue);
​
  compareValue = TIMER_CaptureGet(TIMER0, 1);
    /* decrement duty-cycle or reset if reached MIN value */
  if( compareValue == 0)
    TIMER_CompareBufSet(TIMER0, 1, TIMER_TopGet(TIMER0));
  else
    TIMER_CompareBufSet(TIMER0, 1, --compareValue);
  }
    /* sets the given duty-cycle value to the timer */
  else if ( pwm_mode >= 0 && pwm_mode <= 100)
  {
          // IF YOU USE BGM121 change 1-0.01*pwm_mode to pwm_mode/100.
      TIMER_CompareBufSet(TIMER0, 1, TIMER_TopGet(TIMER0)*(1-0.01*pwm_mode));
      TIMER_CompareBufSet(TIMER0, 0, TIMER_TopGet(TIMER0)*(1-0.01*pwm_mode));
​
  }
}

8. And finally, the case which configures the pwm_mode variable.

switch (BGLIB_MSG_ID(evt->header)){
.
.
.
case gecko_evt_gatt_server_attribute_value_id:
          if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_Control_Value){
            pwm_mode = 0;
              pwm_mode = ((uint16_t) evt->data.evt_gatt_server_user_write_request.value.data[0]);
          }
          break;
    .
    .
    .   
}

9. Build and flash the app to your preferred device.

Running the Example

Open the Blue Gecko app on your mobile, then open the Bluetooth Browser tab and connect to the device, the name will display as “PWM_Exam”.

• Change the decimal value between 0-255 and observe the results with on-board LEDs. You can modify the pins for you custom design.

Additional Reading

For more information on the timers please see https://www.silabs.com/documents/public/application-notes/AN0014.pdf.

Introduction

The Bluetooth SDK 2.4 introduced a new bond replacement algorithm which makes bonding process smarter. There is only limited amount of flash reserved for storing bonds and the new algorithm uses it more efficiently in order to decrease unnecessary flash writes.

How it Works

Using the new algorithm, bonded devices are stored in a list which is divided into two parts: active bondings and inactive bondings. At the picture below active bondings are marked with green and inactive bondings are marked with red.

The working principle of new algorithm is shown in the picture above and it is based on three rules.

1. When new bonding is created, it is added top of the bondings list. If list is full, then last bonding is dropped out of the list.

1. When connection is opened and if device is in inactive bonding list, it is moved on top of the active bondings list. If device is in active bondings list no actions is done.

1. When list is updated it is saved into flash.

The new bond replacement algorithm does not require intervention from the application. The size of the inactive bondings list is 1/3 of the maximum number of bondable devices rounded up. The maximum number of bondable devices is configured with the max_bonding_count parameter in sm_store_bonding_configuration command.

How to enable

To enable this new algorithm, you need to use cmd_sm_store_bonding_configuration command and change policy_flags value to 2. Note that you need SDK version 2.4.0 or later. I added some explanation below. 

gecko_cmd_sm_store_bonding_configuration(uint8 max_bondi
ng_count, uint8 policy_flags);

Max_bonding_count is the maximum number of bonds saved in the peripheral storage storage and it can have values from 1-14. Policy_flags defines bonding mode. The following modes are available:
• 0: If database is full, new bonding attempts will fail
• 1: New bonding will overwrite the oldest existing bonding
• 2: New bonding will overwrite longest time ago used existing
bonding (This is The New Bond Replacement Algorithm)

On EFR32 SoC based designs there is the possibility to supply the PAVDD (Power Amplifier voltage regulator VDD input) from the output of the DC/DC or straight from a 3.3V power supply.

Figure 1 - Direct supply power configuration without DC-DC converter

Figure 2 - Power configuration with DC-DC converter

The Bluetooth stack configuration defaults to the usage of DC/DC as the PAVDD input but if PAVDD is actually being supplied from an 3.3V power supply then the 2 following lines must be added to the bluetooth configuration structure.

/* Gecko configuration parameters (see gecko_configuration.h) */
static const gecko_configuration_t config = {
 .........................................................
 .........................................................
  .pa.config_enable = 1,
  .pa.input = GECKO_RADIO_PA_INPUT_VBAT, 
 .........................................................
 .........................................................
};

If these 2 lines are not added then the transmit power configured through the command  system_set_tx_power will not be valid and the real RF transmit power can be a few dB higher than what is returned by the stack in the command response.

EFR32BG12 devices have 1MB internal flash memory. This makes it possible to store multiple firmware images in the internal flash (the Bluetooth stack size is around 128kB + application), and to switch between these firmwares at boot time.

For two firmware images the flash is split into 4 section:

• The actual application that is executed (starting at 0x0000)
• The first firmware image packed into GBL format (in slot0)
• The second firmware image packed into GBL format (in slot1)
• The Gecko bootloader (placed into the bootloader section)

Before rebooting the device, the bootloader can be instructed to boot an image from slot0 or from slot1 to the application area. Then upon reboot, the bootloader parses the GBL file, copies the application image from it to address 0x0000 and starts execution.

This article shows a simple example how to program the flash for this use case and how to switch between firmware images.

The Gecko Bootloader

The Gecko Bootloader is a common bootloader for EFR32BG devices that can be configured in a number of ways. For this use case we need the so called Internal Storage Bootloader configuration.

1. Connect your device to your PC
2. Open Simplicity Studio
3. Select your device in the Devices tab
4. Select Bluetooth SDK 2.3.0 or later as preferred SDK
5. Find Internal Storage Bootloader (multiple images) between the Software Examples and click on it. This will create a new Gecko Bootloader project. The AppBuilder opens automatically.
6. Click on the Storage tab. Check the address of Slot0 and Slot1. (You may also rearrange the slots and create new slots for firmware images)
7. Click Generate in the upper right corner. This will generate the full Bootloader project.
8. Click Project > Build project
9. Start Simplicity Commander
10. Connect to your device with Simplicity Commander
11. Click on the Flash tab
12. Browse for bootloader-storage-internal-combined.s37 in your workspace (this image contains the whole bootloader)
13. Click Flash to flash the bootloader image into the device

Sample Application

As a simple example we will use the SoC-Empty app. This application implements a simple Bluetooth server which is advertising and can be connected to. We will add a new characteristic to the app with which the device can be instructed to boot from another slot.

1. Connect your device to your PC
2. Open Simplicity Studio
3. Select your device in the Devices tab
4. Select Bluetooth SDK 2.3.0 or later as preferred SDK
5. Find SoC-Empty between the software examples and click on it. This will create a new bluetooth application project. The AppBuilder opens automatically.
6. Click on the Device Name characteristic in the upper right corner of the main window.
7. Change its value from „Empty Example” to „Application 1” – this will differentiate app image 1 and app image 2
8. With the help of the icons on the right side add a new Service to the GATT database
9. With the help of the icons on the right side add a new Characteristic to the GATT database within the newly added service – this characteristic will be used to switch between slots
10. Click on the new Characteristic and in the Characteristic settings tick the checkbox next to ID
11. Enter an ID for the characteristic: boot_slot
12. In the Properties tab add Write property to the characteristic
13. Press Generate in the upper right corner. This will generate the Bluetooth application project.

1. Open main.c
2. Add the following includes:

   #include "btl_interface.h"
   #include "btl_interface_storage.h"

3. Add the following lines to the main switch statement:

   case gecko_evt_gatt_server_attribute_value_id:
     if (evt->data.evt_gatt_server_attribute_value.attribute == gattdb_boot_slot)
     {
       bootloader_setImageToBootload((int32_t)(evt->data.evt_gatt_server_attribute_value.value.data[0]));
       bootloader_rebootAndInstall();
     }
     break;

4. Add "${StudioSdkPath}/platform/bootloader" to the include libraries of the project (Project > Properties > C/C++ build > Settings > Includes)
5. Copy btl_interface.c and btl_interface_storage.c from C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.1\platform\bootloader\api to your project
6. Press Project > Build project
7. Run create_ebl_files.bat or create_bl_files.bat by double clicking on it. You will find one of them in your project
8. Find soc-empty.bin in the output folder of the compiler. Rename it to app1.bin.
9. Find full.gbl in the output_gbl folder, and rename it to app1.gbl.bin. It is important to rename it to a .bin file to be able to flash it into the internal flash.

Now the first firmware image is ready. To create a second image we will slightly modify this project:

1. Double click on the .isc file in your project. This will open the AppBuilder
2. Select the Device Name characteristic again
3. Change its value to „Application 2”
4. Press Generate
5. Press Project > Build project
6. Run create_ebl_files.bat or create_bl_files.bat by double clicking on it.
7. Find soc-empty.bin in the output folder of the compiler. Rename it to app2.bin.
8. Find full.gbl in the output_gbl folder, and rename it to app2.gbl.bin.

Programming the Flash

To program the flash correctly do the followings:

1. Open Simplicity Commander
2. Connect to your device with Simplicity Commander
3. Click on the Flash tab
    
4. Browse for app1.bin in your workspace
5. Set the Flash start address to 0x00000000
6. Click Flash to flash the application image into the device
    
7. Browse for app1.gbl.bin in your workspace
8. Set the Flash start address to the address of Slot0 (0x0005a000 by default). Be careful, Commander expects a hexadecimal address
9. Click Flash to flash the gbl file into the device
    
10. Browse for app2.gbl.bin in your workspace
11. Set the Flash start address to the address of Slot1 (0x000ac800 by default). Be careful, Commander expects a hexadecimal address
12. Click Flash to flash the gbl file into the device

Note: you may also upload GBL files OTA to the slots following the instructions of this article:

http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/Uploading-images-to-slots-using-OTA-DFU/ta-p/210425

Testing

You can test the application with the Blue Gecko Android/iOS app (http://silabs.com/bluegeckoapp)

1. Open the Blue Gecko app on your smartphone
2. Click on Bluetooth Browser
3. You will see the device advertising as Application 1
4. Click on it to connect
5. Find the Unknown Characteristic within the Unknown Service
6. Click the Edit icon and write 01 to the Characteristic. This will trigger the device to reboot from Slot 1
7. Disconnect from the device by clicking on the Back arrow
8. Now you will see the device advertising as Application 2

Note: This article is marked as deprecated. The recommendation is that you select the correct toolchain at project creation time and do not switch it afterwards.

Since BLE SDK 2.4.0 GCC is officially supported.

If an existing project was using IAR but you want switch to GCC you have the following options.

A - Restart the project from scratch but this time select GCC as a toolchain.

B - Change the toolchain to GCC in the project configuration of the existing IAR project.

This article is showing the steps for the option B below.

1. Go to Project->Build Configurations->Manage..

2. Create a new build configuration by New..

3. Select GNU ARM v4.9.3 – default option. Then press OK.

4. Set the newly created GNU ARM configuration active. You can delete the IAR ARM configuration if you are sure that you don’t want to switch back for IAR in the future.

5. Go to File-> Properties for opening the project properties window. Go to C/C++ build -> Settings then select Memory Layout on the Tool Settings tab. Make sure the project configuration is GNU ARM. Now browse for the linker script of your device.

6. Open the .isc file on your workspace with text editor.

7. Replace the iar with gcc in the line which starts with architecture. Save the .isc with CTRL + S.

8. Close the .isc and reopen with double click. Press Generate.

9. Optional step: If your project using additional header or library files then the built in SDK examples you may add their paths to project on the project configuration window. See point 5.

10. Now build your project. (CTRL + B). The project should build with GCC without errors.

Introduction

This article shows how to configure the TX and RX activity indicators when using Bluetooth SDK 2.4.0 or later. 

The TX and RX activity signals can be used to monitor the radio activity. Following screen capture from logic analyzer shows an example where Channel 0 is showing the RX activity and Channel 1 is showing TX activity.

The picture above shows one advertising event. The advertisement is transmitted on all three channels (three pulses in the TX indicator). After sending packet on one channel the receiver is active for short period of time so that possible connection or scan requests can be detected.

TX/RX indicators in BLE SDK 2.3.x and earlier

In SDK versions 2.3.x and earlier, there has been two alternative ways to configure the RX/TX indicator pins:

BGScript applications: using the <obssel> tag in hardware.xml file

  <!-- Enable TX and RX indication pins -->
  <obssel rx_obs_pin="6" tx_obs_pin="7" />

C applications: using the radio_obs field in the gecko_configuration_t struct:

//   gecko_configuration_t settings:
  .radio_obs.rx_pin=6,
  .radio_obs.tx_pin=7,
  .radio_obs.flags=0x1,

Both of these options are removed starting from BLE SDK 2.4.0. (BGScript support in general is removed starting from this version).

TX/RX indicators in BLE SDK 2.4.0 and later

In projects built with SDK 2.4.0 or later, the RX/TX activity pins can still be configured in the user application. The files attached to the end of this article include functions to configure the TX and RX pins separately. 

Example usage: you can use for example the SoC Empty template as starting point. Add the files obssel.h, obssel.c to the project. After the call to gecko_init() configure the TX and RX indicators to the desired pins (allowed range : port C, pins 6..11)

// needs to be added in the beginning of file:
 #include "obssel.h"

....

  /* Initialize stack */
  gecko_init(&config);

  obssel_rx_setup(6);  // map RX activity to PC6
  obssel_tx_setup(7);  // map TX activity to PC7

The header obssel.h includes some defines that depend on the target hardware. Make sure that you configure the code to match your target hardware:

//From obssel.h:

/* uncomment one of the following defines, depending on your target device
 *
 * EFR32BG1:  this setting is valid for BGMxxx modules and EFR32BG1 SoC designs
 * EFR32BG1X: valid for EFR32BG12, EFR32BG13
 * */

#define EFR32BG1
// #define EFR32BG1X

Since SDK 2.4.0 NCP target project structure changed. Therefore upgrading a project to the latest Bluetooth SDK is not trivial. This article will guide you trough the migration process.

1. Install Bluetooth SDK 2.4.x via the package manager of Simplicity Studio.

2. Create a NCP-empty-target example.

3.Open the .isc file on your workspace and import the GATT of your old project.

4. Save and Generate.

5. Configure the UART interface. Since Bluetooth SDK 2.4.0 it has to be done in ncp_usart_conf.h and not in the hardware configurator GUI. The configuration options are documented in AN1042 chapter 4.1.1. https://www.silabs.com/documents/login/application-notes/an1042-bt-ncp-mode.pdf

6. Configure the sleep options. Since Bluetooth SDK 2.4.0 it has to be done in ncp_usart_conf.h and not in the gecko_init function. The configuration options are documented in AN1042 chapter 4.1.4.