Note: This KBA has been marked as deprecated. A more updated KBA can be found here:Using Hardware Timers
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.
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.
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.
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.
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.
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.
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.
Connect your device to your PC
Open Simplicity Studio
Select your device in the Devices tab
Select Bluetooth SDK 2.3.0 or later as preferred SDK
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.
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)
Click Generate in the upper right corner. This will generate the full Bootloader project.
Click Project > Build project
Start Simplicity Commander
Connect to your device with Simplicity Commander
Click on the Flash tab
Browse for bootloader-storage-internal-combined.s37 in your workspace (this image contains the whole bootloader)
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.
Connect your device to your PC
Open Simplicity Studio
Select your device in the Devices tab
Select Bluetooth SDK 2.3.0 or later as preferred SDK
Find SoC-Empty between the software examples and click on it. This will create a new bluetooth application project. The AppBuilder opens automatically.
Click on the Device Name characteristic in the upper right corner of the main window.
Change its value from „Empty Example” to „Application 1” – this will differentiate app image 1 and app image 2
With the help of the icons on the right side add a new Service to the GATT database
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
Click on the new Characteristic and in the Characteristic settings tick the checkbox next to ID
Enter an ID for the characteristic: boot_slot
In the Properties tab add Write property to the characteristic
Press Generate in the upper right corner. This will generate the Bluetooth application project.
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;
Add "${StudioSdkPath}/platform/bootloader" to the include libraries of the project (Project > Properties > C/C++ build > Settings > Includes)
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
Press Project > Build project
Run create_ebl_files.bat or create_bl_files.bat by double clicking on it. You will find one of them in your project
Find soc-empty.bin in the output folder of the compiler. Rename it to app1.bin.
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:
Double click on the .isc file in your project. This will open the AppBuilder
Select the Device Name characteristic again
Change its value to „Application 2”
Press Generate
Press Project > Build project
Run create_ebl_files.bat or create_bl_files.bat by double clicking on it.
Find soc-empty.bin in the output folder of the compiler. Rename it to app2.bin.
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:
Open Simplicity Commander
Connect to your device with Simplicity Commander
Click on the Flash tab
Browse for app1.bin in your workspace
Set the Flash start address to 0x00000000
Click Flash to flash the application image into the device
Browse for app1.gbl.bin in your workspace
Set the Flash start address to the address of Slot0 (0x0005a000 by default). Be careful, Commander expects a hexadecimal address
Click Flash to flash the gbl file into the device
Browse for app2.gbl.bin in your workspace
Set the Flash start address to the address of Slot1 (0x000ac800 by default). Be careful, Commander expects a hexadecimal address
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:
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.
What is the strength of the internal pull up on the BGM113 RESETn pin?
Answer
The internal pull-up on the BGM113 reset line (RESETn) is the same as those present on other GPIO pins, and is specified in the BGM113 Data Sheet by the "I/O pin pull-up resistor" (RPU) parameter in Table 4.20 "GPIO" (of section 4.1.11 GPIO). RPU is specified as 30/43/65 kOhm (min/typ/max) in the revision 1.00 data sheet.
Is EFR32xG12 in the QFN48 package a drop-in replacement for earlier EFR32xG1 devices?
Answer
The EFR32xG12 is a drop-in replacement for QFN48-packaged EFR32xG1 applications except where vias have been located between pins and exposed GND pad, as these vias risk shorting to GND over time (depending on solder mask quality). To avoid this concern, do not place vias in this region.
The following images depict EFR32xG12 and EFR32xG1 devices installed on a EFR32xG1 footprint:
Refer to the EFR32xG12 and EFR32xG1 datasheets for more information regarding package dimensions.
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
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 Emptytemplate 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.
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.
Bluetooth Knowledge Base
[Deprecated] KBA_BT_1004: Hardware Timers with EFR32xG1x
Note: This KBA has been marked as deprecated. A more updated KBA can be found here: Using Hardware Timers
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.
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
4. We initialize pins and enable clocks. In the example, WSTK LEDs are used.
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.
6. The timer properties and initializing is done in this section.
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).
8. And finally, the case which configures the pwm_mode variable.
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.
[Deprecated] KBA_BT_1104: The New Bond Replacement Algorithm
Note: This KBA has been marked as deprecated. A more updated KBA can be found here:
Using Bluetooth Security Features in Silicon Labs SDK
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.
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.
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)
[Deprecated] KBA_BT_1302: Supplying EFR32 PAVDD from 3.3V
Note: This KBA has been marked as deprecated. A more updated KBA can be found here:
Bluetooth TX Power Settings
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.
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.
KBA_BT_0604: Switching between firmware images using Internal Storage Bootloader
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:
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.
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.
Now the first firmware image is ready. To create a second image we will slightly modify this project:
Programming the Flash
To program the flash correctly do the followings:
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)
[Deprecated] Switching to GCC
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.
BGM113 Reset Pull-up Pin Strength
EFR32xG12 QFN48 Footprint Differences
[Deprecated] KBA_BT_0307: Enabling TX/RX activity indicator pins in BLE SDK 2.4.0 and later
Note: This KBA has been marked as deprecated. A more updated KBA can be found here:
TX and RX Activity Indicator Pins
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
C applications: using the radio_obs field in the gecko_configuration_t struct:
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)
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:
KBA_BT_1401: Updating NCP projects to SDK 2.4.x
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.