...but I stumbled on conflicting definitions of LDMA_IRQHandler from the required "dmadrv" module (I believe the serial plugin uses this).
Are you planning on integrating CSLIB with Bluetooth sample projects anytime soon? Perhaps in the form of a plugin?
For starters, it's important to note that the sample Bluetooth projects include dmadrv.c in the bgapi folder. DMADRV is a component of emdrv, a driver abstraction layer that is part of the Gecko SDK platform. Other commonly used emdrv components include GPIOINT for pin interrupt event callback dispatching, UARTDRV for asynchronous serial communications, and USTIMER for microsecond-level delays.
Emdrv, in turn, sits on top of emlib, which is the hardware abstraction layer for the EFM32 and EFR32 device families and is also part of the Gecko SDK platform. Given that dmadrv.c is included in sample Bluetooth projects, it should come as no surprise that em_ldma.c is, too. So, while emlib simplifies the task of configuring the underlying MCU hardware on a given EFM32 or EFR32 device, emdrv allows portable code to be written that can run on any EFM32 or EFR32 device.
Although both dmadrv.c and em_ldma.c are included in the sample Bluetooth projects, such as soc-smartPhone, it might come as a surprise that none of the samples actually use LDMA. Given this, can't the existing CSLIB code for EFM32PG12 simply be grafted into an EFR32BG12 project? The answer is "not exactly" because an implementation of LDMA_IRQHandler() is found in the device_CSEN/hardware_routines.c file that is a required part of all projects that make use of CSLIB:
void LDMA_IRQHandler(void)
{
uint32_t pending;
/* Read and clear interrupt source */
pending = LDMA_IntGetEnabled();
if ((pending & 3) == 3) {
/* Setup LDMA for next transfer, common for single and scan mode */
LDMA->IFC = 0x03;
setupCSENdataDMA();
CSLIB_autoScanComplete = 1;
CSENtimerTick = 1;
}
}
The trouble arises because DMADRV has its own implementation of LDMA_IRQHandler() in order to dispatch callback functions. Other components of emdrv, like UARTDRV and SPIDRV depend on DMADRV, so removing dmadrv.c will not eliminate the conflict. As an alternative, would it be possible to rewrite the LDMA-related functions in CSLIB to make use of DMADRV? Looking again at the code in device_CSEN/hardware_routines.c reveals another area of concern:
As you might imagine, this programming of the LDMA is not possible because DMADRV must handle the allocation of all channels and manage all descriptors. This is especially important when you consider that DMADRV manages LDMA resources dynamically while the emlib code above does so in a static fashion. Put simply, DMADRV and CSLIB, as currently written, cannot coexist because it would be a case of the right hand not knowing what the left is doing.
So, if CSLIB compatibility with DMADRV isn't immediately possible (more on this later), would it be possible to exclude DMADRV from a Bluetooth project and allow CSLIB to manage the LDMA? As noted above, the Bluetooth examples don't make use of DMADRV. Why not exclude it altogether?
While this entails giving up emdrv and making use of emlib to write peripheral drivers, it is, arguably, the simplest option for integrating CSLIB functionality into a Bluetooth stack application. After creating a new project, say from one of the existing examples, either delete dmadrv.c from the bgapi folder or disable it via Properties -> C/C++ Build -> Exclude resource from build when right-clicking on the file. Having done this, CSLIB can be added to the project. Just be sure to add the CSLIB middleware directories to the project's #include paths along with the relevant source files.
Plug-in support for CSLIB across the various Silicon Labs radio stacks is in development. In the meantime, for users requiring emdrv support, the only option would be to dig into device_CSEN/hardware_routines.c and rewrite the relevant functions to use DMADRV. The first and most obvious task would be to eliminate the LDMA_IRQHandler() instance and replace it with a callback function.
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
GRANT
REQUEST
PRIORITY
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
// Enable 802.11 co-ex feature in gecko_init
#define HAL_COEX_ENABLE 1
// Request window in microseconds
// How many us before the TX/RX request signal is enabled
#define HAL_COEX_REQ_WINDOW 500
// Grant signal polarity, pin and port
#define BSP_COEX_GNT_ASSERT_LEVEL 0
#define BSP_COEX_GNT_PIN 12
#define BSP_COEX_GNT_PORT gpioPortD
// Priority signal polarity, pin and port
#define BSP_COEX_PRI_ASSERT_LEVEL 0
#define BSP_COEX_PRI_PIN 11
#define BSP_COEX_PRI_PORT gpioPortD
// Request signal polarity, pin and port
#define BSP_COEX_REQ_ASSERT_LEVEL 0
#define BSP_COEX_REQ_PIN 10
#define BSP_COEX_REQ_PORT gpioPortD
// Shared request in case multiple EFR32 radios are used
#define HAL_COEX_REQ_SHARED 0
// Enable priority signal (set both to 1)
#define HAL_COEX_TX_HIPRI 1
#define HAL_COEX_RX_HIPRI 1
// Abort TX if grant is denied during ongoing TX operation
#define HAL_COEX_TX_ABORT 1
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
Enable/disable coexistence: coex_option_enable
Abort TX in GRANT denial: coex_option_tx_abort
Enable/disable high PRIORITY: coex_option_high_priority
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
This KBA summarizes the Coexistence feature then walks through on how to enable the feature in a Bluetooth SDK project. Finally, it shows how the Coexistence signals behave while the Bluetooth device advertising, scanning or in connection.
What is Coexistence?
Coexistence feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and described in IEEE 802.15.2 (2003) Clause 6. PTA is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case, Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK 2.6.0 supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices. In later SDK versions the 1 and 2 wire options will be supported also.
In 3-Wire PTA 3 signals defined
GRANT
REQUEST
PRIORITY
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typical 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace. Unfortunately, the BLE SDK 2.6.0 release does not let to disable a PTA pin. However, it is possible to redirect PRIORITY to a not connected GPIO or even to an unbonded GPIO pad for given package.
Project setup
To enable the Coexistence feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
Coexistence library path is depending on the MCU variant and the compiler. See the default path for EFR32BG1B device using GCC compiler
The Coexistence library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
Coexistence configuration
Once the libcoex.a library added to the project the Coexistence feature has to be configured for the system needs. There are options which can be configured at compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
// Enable 802.11 co-ex feature in gecko_init
#define HAL_COEX_ENABLE 1
// Request window in microseconds
// How many us before the TX/RX request signal is enabled
#define HAL_COEX_REQ_WINDOW 500
// Grant signal polarity, pin and port
#define BSP_COEX_GNT_ASSERT_LEVEL 0
#define BSP_COEX_GNT_PIN 12
#define BSP_COEX_GNT_PORT gpioPortD
// Priority signal polarity, pin and port
#define BSP_COEX_PRI_ASSERT_LEVEL 0
#define BSP_COEX_PRI_PIN 11
#define BSP_COEX_PRI_PORT gpioPortD
// Request signal polarity, pin and port
#define BSP_COEX_REQ_ASSERT_LEVEL 0
#define BSP_COEX_REQ_PIN 10
#define BSP_COEX_REQ_PORT gpioPortD
// Shared request in case multiple EFR32 radios are used
#define HAL_COEX_REQ_SHARED 0
// Enable priority signal (set both to 1)
#define HAL_COEX_TX_HIPRI 1
#define HAL_COEX_RX_HIPRI 1
// Abort TX if grant is denied during ongoing TX operation
#define HAL_COEX_TX_ABORT 1
Coexistence API
The Coexistence feature has to be initialized by calling gecko_initCoexHAL() API function. For convenience, this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
Enable/disable coexistence: coex_option_enable
Abort TX in GRANT denial: coex_option_tx_abort
Enable/disable high PRIORITY: coex_option_high_priority
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case, all devices share the same REQUEST, PRIORITY, and GRANT signals, therefore, it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
Coexistence signals in practice
In this setup, all 3 Coexistence signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
Coexistencesignals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
Coexistence signals in scannig
During the scan interval, the REQUEST signal is active and the radio gets RX interrupts as it is indicated by the RX signal.
Coexistence signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because of the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real-world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
Or you can configure the radio signals directly with the code snippets below:
#include <em_cmu.h>
#include <em_gpio.h>
CMU_ClockEnable(cmuClock_PRS, true); // Enable PRS clock
CMU_ClockEnable(cmuClock_GPIO, true); // Enable GPIO clock
GPIO_PinModeSet(gpioPortC, 10, gpioModePushPull, 0); // Set PC10 GPIO mode to push-pull
GPIO_PinModeSet(gpioPortC, 11, gpioModePushPull, 0); // Set PC11 GPIO mode to push-pull
PRS->CH[10].CTRL = PRS_RAC_RX | PRS_CH_CTRL_EDSEL_OFF; // Set PRS channel 10 for RX
PRS->CH[11].CTRL = PRS_RAC_TX | PRS_CH_CTRL_EDSEL_OFF; // Set PRS channel 11 for TX
PRS->ROUTELOC2 &= ~_PRS_ROUTELOC2_CH10LOC_MASK; // Route the PRS ch 10 to LOC4(PC10)
PRS->ROUTELOC2 |= PRS_ROUTELOC2_CH10LOC_LOC4;
PRS->ROUTELOC2 &= ~_PRS_ROUTELOC2_CH11LOC_MASK; // Route the PRS ch 11 to LOC4(PC11)
PRS->ROUTELOC2 |= PRS_ROUTELOC2_CH11LOC_LOC4;
PRS->ROUTEPEN |= PRS_ROUTEPEN_CH10PEN | PRS_ROUTEPEN_CH11PEN; // Enable PRS signals
GPIO pins
On the Bluetooth device 3 GPIO pin needs to be assigned for the REQUEST, PRIORITY and GRANT signals. For the optional RX/TX signals 2 more GPIO pin is needed.
PRS channel allocation
The REQUEST, PRIORITY and GRANT signals does not require PRS channels. But for the optional RX/TX signals 2 PRS channel is needed.
In Bluetooth SDK 2.6.0 PRS channel 7 is allocated to the Bluetooth stack so it can not be used for the RX/TX signals. PRS channel allocation may change in the future so please check the UG136 chapter 7 for the unused PRS channels.
NCP mode
In case of NCP mode the ncp_gecko_bgapi_class_coex_init() need to be called additionaly after gecko_init().
Custom boards
On custom boards, the init_board.c is empty. For using the coexistence feature the GPIO clock has to be enabled as shown below.
Bluetooth Knowledge Base
Can CSLIB be used with the Bluetooth SDK?
I'm wondering if/when you'll have a sample project for utilizing the capacitive touch features of the EFR32 parts.
As an investigation, I tried porting the sample code found in...
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\app\mcu_example\SLSTK3402A_EFM32PG12\cslib
...but I stumbled on conflicting definitions of LDMA_IRQHandler from the required "dmadrv" module (I believe the serial plugin uses this).
Are you planning on integrating CSLIB with Bluetooth sample projects anytime soon? Perhaps in the form of a plugin?
For starters, it's important to note that the sample Bluetooth projects include dmadrv.c in the bgapi folder. DMADRV is a component of emdrv, a driver abstraction layer that is part of the Gecko SDK platform. Other commonly used emdrv components include GPIOINT for pin interrupt event callback dispatching, UARTDRV for asynchronous serial communications, and USTIMER for microsecond-level delays.
Emdrv, in turn, sits on top of emlib, which is the hardware abstraction layer for the EFM32 and EFR32 device families and is also part of the Gecko SDK platform. Given that dmadrv.c is included in sample Bluetooth projects, it should come as no surprise that em_ldma.c is, too. So, while emlib simplifies the task of configuring the underlying MCU hardware on a given EFM32 or EFR32 device, emdrv allows portable code to be written that can run on any EFM32 or EFR32 device.
Although both dmadrv.c and em_ldma.c are included in the sample Bluetooth projects, such as soc-smartPhone, it might come as a surprise that none of the samples actually use LDMA. Given this, can't the existing CSLIB code for EFM32PG12 simply be grafted into an EFR32BG12 project? The answer is "not exactly" because an implementation of LDMA_IRQHandler() is found in the device_CSEN/hardware_routines.c file that is a required part of all projects that make use of CSLIB:
The trouble arises because DMADRV has its own implementation of LDMA_IRQHandler() in order to dispatch callback functions. Other components of emdrv, like UARTDRV and SPIDRV depend on DMADRV, so removing dmadrv.c will not eliminate the conflict. As an alternative, would it be possible to rewrite the LDMA-related functions in CSLIB to make use of DMADRV? Looking again at the code in device_CSEN/hardware_routines.c reveals another area of concern:
As you might imagine, this programming of the LDMA is not possible because DMADRV must handle the allocation of all channels and manage all descriptors. This is especially important when you consider that DMADRV manages LDMA resources dynamically while the emlib code above does so in a static fashion. Put simply, DMADRV and CSLIB, as currently written, cannot coexist because it would be a case of the right hand not knowing what the left is doing.
So, if CSLIB compatibility with DMADRV isn't immediately possible (more on this later), would it be possible to exclude DMADRV from a Bluetooth project and allow CSLIB to manage the LDMA? As noted above, the Bluetooth examples don't make use of DMADRV. Why not exclude it altogether?
While this entails giving up emdrv and making use of emlib to write peripheral drivers, it is, arguably, the simplest option for integrating CSLIB functionality into a Bluetooth stack application. After creating a new project, say from one of the existing examples, either delete dmadrv.c from the bgapi folder or disable it via Properties -> C/C++ Build -> Exclude resource from build when right-clicking on the file. Having done this, CSLIB can be added to the project. Just be sure to add the CSLIB middleware directories to the project's #include paths along with the relevant source files.
Plug-in support for CSLIB across the various Silicon Labs radio stacks is in development. In the meantime, for users requiring emdrv support, the only option would be to dig into device_CSEN/hardware_routines.c and rewrite the relevant functions to use DMADRV. The first and most obvious task would be to eliminate the LDMA_IRQHandler() instance and replace it with a callback function.
Enabling COEX feature in Bluetooth SDK projects
Introduction
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\protocol\bluetooth_2.6\lib\EFR32BG1B\GCC\libcoex.a
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/07/04/enabling_tx_rx_activ-V4T1
Or you can configure the radio signals directly with the code snippets below:
References
IEEE 802.15.2 (2003) Clause 6
https://www.silabs.com/documents/public/application-notes/an1017-coexistence-with-wifi.pdf
http://www.embedded-computing.com/embedded-computing-design/driving-wi-fi-zigbee-and-thread-coexistence-in-the-2-4-ghz-band-part-2-managed-coexistence
[Deprecated] KBA_BT_0303: Enabling Coexistence Feature in Bluetooth SDK projects
Note: This KBA is deprecated. For Wi-Fi and Bluetooth coex please refer to AN1128: Bluetooth® Coexistence with Wi-Fi
Introduction
This KBA summarizes the Coexistence feature then walks through on how to enable the feature in a Bluetooth SDK project. Finally, it shows how the Coexistence signals behave while the Bluetooth device advertising, scanning or in connection.
What is Coexistence?
Coexistence feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and described in IEEE 802.15.2 (2003) Clause 6. PTA is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case, Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK 2.6.0 supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices. In later SDK versions the 1 and 2 wire options will be supported also.
In 3-Wire PTA 3 signals defined
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typical 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace. Unfortunately, the BLE SDK 2.6.0 release does not let to disable a PTA pin. However, it is possible to redirect PRIORITY to a not connected GPIO or even to an unbonded GPIO pad for given package.
Project setup
To enable the Coexistence feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
Coexistence library path is depending on the MCU variant and the compiler. See the default path for EFR32BG1B device using GCC compiler
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\protocol\bluetooth_2.6\lib\EFR32BG1B\GCC\libcoex.a
The Coexistence library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
Coexistence configuration
Once the libcoex.a library added to the project the Coexistence feature has to be configured for the system needs. There are options which can be configured at compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
Coexistence API
The Coexistence feature has to be initialized by calling gecko_initCoexHAL() API function. For convenience, this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case, all devices share the same REQUEST, PRIORITY, and GRANT signals, therefore, it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
Coexistence signals in practice
In this setup, all 3 Coexistence signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
Coexistence signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
Coexistence signals in scannig
During the scan interval, the REQUEST signal is active and the radio gets RX interrupts as it is indicated by the RX signal.
Coexistence signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because of the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real-world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/07/04/enabling_tx_rx_activ-V4T1
Or you can configure the radio signals directly with the code snippets below:
GPIO pins
On the Bluetooth device 3 GPIO pin needs to be assigned for the REQUEST, PRIORITY and GRANT signals. For the optional RX/TX signals 2 more GPIO pin is needed.
PRS channel allocation
The REQUEST, PRIORITY and GRANT signals does not require PRS channels. But for the optional RX/TX signals 2 PRS channel is needed.
In Bluetooth SDK 2.6.0 PRS channel 7 is allocated to the Bluetooth stack so it can not be used for the RX/TX signals. PRS channel allocation may change in the future so please check the UG136 chapter 7 for the unused PRS channels.
NCP mode
In case of NCP mode the ncp_gecko_bgapi_class_coex_init() need to be called additionaly after gecko_init().
Custom boards
On custom boards, the init_board.c is empty. For using the coexistence feature the GPIO clock has to be enabled as shown below.
References
IEEE 802.15.2 (2003) Clause 6
https://www.silabs.com/documents/public/application-notes/an1017-coexistence-with-wifi.pdf
http://www.embedded-computing.com/embedded-computing-design/driving-wi-fi-zigbee-and-thread-coexistence-in-the-2-4-ghz-band-part-2-managed-coexistence
https://www.silabs.com/documents/login/user-guides/ug136-ble-c-soc-dev-guide.pdf