The EFR32 families of chips each come equipped with multiple Power Amplifiers (PAs):
EFR32xG1x
A high-power * 2.4 GHz PA (for power 20 dBm and lower)**
A low-power 2.4 GHz PA (for power 0 dBm and lower)
A Sub-GHz PA**
EFR32xG21
A high-power 2.4 GHz PA (for power 20 dBm and lower)**
A medium-power 2.4 GHz PA (for power 10 dBm and lower)
A low-power 2.4 GHz PA (for power 0 dBm and lower)
EFR32xG22
A high-power 2.4 GHz PA (for power 6 dBm and lower)**
A low-power 2.4 GHz PA (for power 0 dBm and lower)
Each of these PAs has a unique number of discrete “power levels”, which are simply abstractions of the different register settings that control the active PA. For each PA, the following power levels are available:
EFR32xG1x
High-power 2.4 Ghz: 0-252**
Low-power 2.4 Ghz: 1-7
Sub-GHz: 0-248
EFR32xG21
High-power 2.4 Ghz: 1-180**
Medium-power 2.4 Ghz: 1-90
Low-power 2.4 Ghz: 1-64
EFR32xG22
High-power 2.4 Ghz: 0-128**
Low-power 2.4 Ghz: 0-15
*Note that the use of 'high', 'medium', and 'low' in the names of these PAs refers to power consumption, not power output. It is possible, for instance, to configure the high-power PA to transmit at a lower dBm output than the low-power PA.
**Maximum power/use of these PAs may be restricted by your specific OPN. Please see the data sheet for more details regarding your particular part.
The purpose of this KBA is to organize all Wireless Hardware related specific/generic technical documents (application notes and KBAs) applicable to EFR32 Series 2 SoCs and Wireless modules in one place. The content is grouped into the following categories to make it easier to find what you are looking for.
This Knowledge Base Article (KBA) aims to organize all Wireless Hardware related technical documents and related individual KBAs for EFR32 Series 1 SoCs and Wireless modules together in one place.
The KBA organizes all technical documents into categories for a better and convenient way to refer to the contents while designing a custom application based on these parts. The categorized RF hardware contents are as follows:-
BSDL files do not exist for EFR32 devices, because there is no boundary-scan TAP in the EFR32. We do have the ARM SWJ-DP which handles JTAG/SWD based accesses to the debug port (DP).
There are 3 ways to request a device to leave the network, although none of them are perfect in that they do not guarantee the result of having a device exit immediately, or to force it to stay out of the network in the future ("kicking out a device").
Here are some descriptions of the leave request methods with pros and cons.
1) Send ZDO Leave to ZR parent with ZED's EUI as target -Pros: Will always succeed (if ZED is still in the child table of ZR and ZR is reachable) with response status, regardless of what ZED's polling rate is. -Cons: If ZED isn't polling parent regularly, parent's NWK Leave command to child could time out before child gets it, and child gets erased anyway. When child polls next time, parent will tell him to leave and rejoin because it's an non-child end device, so that gets you back to before the ZDO Leave.
2) Send ZDO Leave to ZED with ZED's EUI (or all-zero EUI) as target -Pros: ZDO response clearly indicates whether ZED received the leave request. No confusion as above with ZED accidentally being told to rejoin. -Cons: If ZED isn't polling parent regularly, it won't receive this request, so sender needs to be careful about timing of sending the request. In older EmberZNet stack versions (4.6 through 5.4), a bug existed that would sometimes reject a ZDO Leave Request sent to an end device depending on who was the sender. In EmberZNet versions 5.6.0 and earlier, the ZED won't get a ZDO Leave Response out before it leaves the network, so the requester must rely on the APS ACK rather than the ZDO response to confirm receipt.
3) Send APS Remove Device command (emberSendRemoveDevice) to ZR parent with ZED's EUI as deviceToRemove. -Pros: APS-authenticated (unlike ZDO messages), so devices (even SE devices) can't choose to ignore this, and it is harder to spoof because it requires APS encryption. -Cons: Need long address of child and parent for the command. No APS ACK available for APS commands, so can't confirm receipt by the parent. Still may encounter problem where parent deletes child before the child knows it was removed, causing child to rejoin on next poll attempt. Can only be sent by Trust Center.
In general, we recommend a fallback system, such as trying 2 and falling back to 1 (or 3) if it doesn't work.
I'm having trouble getting the processor to sleep using the HA Sample applications in 5.7.3.
Answer
The Utility > EEPROM plugin was left unchecked for the sample apps to allow the apps to be run on modules which do not contain EEPROM. Most of the EFR32/WSTK kit modules do contain EEPROM, so the plugin should be checked before building.
Additionally, in some EFR32/WSTK combinations, the board must be power cycled/reset after the first programming of the boardfor sleep to work.
What peripherals on EFR32MG is the EmberZNet stack using?
Answer
Minimum Requirements
Minimum requirements for proper EmberZNet stack operation are the following:
High Frequency Crystal Oscillator (HFXO) – Needed for high-precision timing on IEEE 802.15.4 MAC layer state machines. (Note: The EFR32 cannot run the radio off of HFRCO. HFXO is needed for high-precision timing on IEEE 802.15.4 MAC layer state machines.)
Real Time Counter/Calendar (RTCC) – Needed to drive millisecond-driven events and sleep timing for stack and application events. Requires either Low Frequency RC Oscillator (LFRCO) or Low Frequency Crystal Oscillator (LFXO) as a clock source.
Energy Management Unit (EMU) Temperature Change (TEMPCHANGE) – Needed to support proper operation over full operating temperature range.
Watchdog Timer (WDOG) – Needed for self-management of code to prevent infinite loops. Requires Ultra-Low Frequency RC Oscillator (ULFRCO) as clock source.
TIMER0 – Needed for microsecond precision delay logic.
Clock Management Unit (CMU) – Needed for setup of clock sources.
Nested Vector Interrupt Controller (NVIC) – Needed for interrupt management.
Cryptographic (CRYPTO) module – Required for stack-level security functions.
Additional Resource Usage
These MCU peripherals may be needed by EmberZNet HAL, or Application Framework, or bootloader under certain use cases.
USART0 – Used for serial interaction with serial bootloader or application’s serial command line interface (CLI) if present.
USART1 – Used for serial interaction with dataflash for bootloader.
LDMA (2 channels out of 8 available) – Used for serial communication.
SerialWire Output (SWO) – Used for debug printing output if desired.
Instruction Trace Macrocell (ITM) – Used for in-system debugging if desired.
Packet Trace Interface (PTI) –Used for capture of TX/RX packets if desired.
Which GPIOs are used on the EFR32MG NCP-UART and NCP-SPI?
Answer
For the pre-built NCP images we include in EmberZNet releases for EFR32MG1P132F256GM48 and EFR32MG1P232F256GM48 variants (included in our Mighty Gecko Wireless SoC Starter Kit):
For proper operation of the EM3xx RF block, it is very important to minimize transmit frequency offset, as well as comply with the 802.15.4 specification of +/-40ppm. The frequency offset is adjusted through the txtone (carrier tone) transmit function, as the 24MHz main clock offset directly relates to the transmitter frequency offset.
Use a spectrum analyzer to measure the frequency offset of the carrier. Set the amplitude reference level higher than the expected output power of the device in order to avoid possible damage to test equipment. For ceramic balun designs, this would be +10dBm, while for PA designs +30dBm should work fine as an initial setting and can be adjusted according to the actual PA TX power maximum capability. Configure the radio to transmit a continuous unmodulated tone at 2445MHz by issuing the commands ‘setchannel 13’ and ‘txtone’ with the nodetest application installed on the device. Measure the frequency offset by selecting the frequency counter setting on the spectrum analyzer followed by a marker peak search. To determine the PPM of the frequency offset, use the following equation:
The frequency offset needs to be improved by adjusting the crystal loading caps only if it appears it will not comply with the +/- 40 PPM 802.15.4 specification. The intent is to tune the frequency to be as close to the desired frequency as possible. Refer to AN700 section 2.6, Transmit Frequency test and KBA article EM35xx-24MHz Crystal Selection for additional information.
How to measure the VDD_PADS voltage on the EM35x series chips?
Answer
The data sheet states "The regulator input voltage, VDD_PADS, cannot be measured using the general purpose ADC, but it can be measured through Ember software." The reason is because VDD_PADS is not one of the selectable analog inputs for the user-exposed ADC, but it is available on the internal CALADC. Hence we provide an API, halMeasureVdd() in the HAL library that does this (per hal/micro/cortexm3/adc.h):
/** @brief Measures VDD_PADS in millivolts at the specified sample rate
* Due to the conversions performed, this function takes slightly under 250us
* with a variation across successive conversions approximately +/-20mv of
* the average conversion.
*
* @return A measurement of VDD_PADS in millivolts.
*/ uint16_t halMeasureVdd(ADCRateType rate);
If VDD_PADS is being driven by a DC-to-DC converter, then the customer would probably want to route the battery voltage input to that also to an analog GPIO of their choice, perhaps voltage divided to meet analog input criteria, and measure that using the normal ADC. There is an API to assist converting the ADC's reading to volts (per hal/micro/adc.h):
/** @brief Convert the raw register value (the unaltered value taken
* directly from the ADC's data register) into a signed fixed point value with
* units 10^-4 Volts. The returned value will be in the range -12000 to
* +12000 (-1.2000 volts to +1.2000 volts).
*
* @appusage Use this function to get a human useful value.
*
* @param value An uint16_t to be converted.
*
* @return Volts as signed fixed point with units 10^-4 Volts.
Zigbee & Thread Knowledge Base
What are the valid values for txPower in EFR32 devices?
The EFR32 families of chips each come equipped with multiple Power Amplifiers (PAs):
Each of these PAs has a unique number of discrete “power levels”, which are simply abstractions of the different register settings that control the active PA. For each PA, the following power levels are available:
*Note that the use of 'high', 'medium', and 'low' in the names of these PAs refers to power consumption, not power output. It is possible, for instance, to configure the high-power PA to transmit at a lower dBm output than the low-power PA.
**Maximum power/use of these PAs may be restricted by your specific OPN. Please see the data sheet for more details regarding your particular part.
For more details and to set custom power curves for your design, refer AN1127: Power Amplifier Power Conversion Functions in RAIL 2.x
Master Wireless Hardware Doc list for EFR32 Series 2 SoCs and Wireless Modules
The purpose of this KBA is to organize all Wireless Hardware related specific/generic technical documents (application notes and KBAs) applicable to EFR32 Series 2 SoCs and Wireless modules in one place. The content is grouped into the following categories to make it easier to find what you are looking for.
[A] EFR32 Series 2 Wireless Modules:
Application Notes
AN1048: Regulatory RF Module Certifications
AN1223: LGA Manufacturing Guidance
KBAs
STEP File information and steps to obtain those files
Design and Assembly guidelines for SiPs
[B] EFR32 Series 2 Wireless SoCs:
AN0002.2: EFR32 Wireless Gecko Series 2 Hardware Design Considerations
AN0948.2: EFR32 Series 2 Power Configurations and DC-DC
AN933.2: EFR32 Series 2 Minimal BOM
AN930.2: EFR32 Series 2 2.4 GHz Matching Guide
AN928.2: EFR32 Series 2 Layout Design Guide
[C] Generic
[1] RF
KBAs
ESD protection of RF devices
RF Range calculator
RF Range factors
Range improvement calculation for a given extra link budget
Data rate, deviation, modulation index for 2GFSK signals
Modulation choice
OBW for digital modulations
Modulation index for digital modulations
RF shield vs. RX immunity
General layer count versus power output recommendations
Custom design PCB number of layers
Recommended routing technique for more layer RF designs
General RF layout suggestions
[2] Certifications
KBAs
Maximum allowed power for ZigBee applications under ETSI EN 300 328
ETSI EN 300 328 Adaptivity Compliance
FCC Harmonic Requirements
TX power limitations for regulatory compliance (ETSI, FCC)
Tips for FCC certification on Silicon Labs' 2.4GHz 802.15.4-based solutions
How to test and estimate TIS/TRP
[3] Antenna
Application Notes
AN1088: Designing with an Inverted-F 2.4 GHz PCB Antenna
APL10045: Antennas for Short Range Devices
AN853: Single-ended Antenna Matrix Design Guide
KBAs
Design tip for dipole antennas
Whip antenna length and size
Whip antenna parameters
Do loop antennas require a ground plane?
PCB antenna with wider bandwidth
Recommended distance between antennas for antenna diversity
Recommended external antenna matching network
How to maximize the isolation of coex. antennas on the same PCB
[4] Coexistence
AN1128: Bluetooth® Coexistence with Wi-Fi®
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
[5] MCU/Peripherals
Application Notes
AN958: Debugging and Programming Interfaces for Custom Designs
AN0016.2: Oscillator Design Considerations
KBAs
EFR32 DCDC powering external circuits
BSDL files
Layout design practices around DC-DC converter
CTUNE Access
HFXO Capacitor Bank (Ctune) calibration on EFR32
Saving CTUNE value as manufacturing token
[6] Testing
Application Notes
AN972: EFR32 RF Evaluation Guide
AN718: Manufacturing Test Overview
AN700.1: Manufacturing Test Guidelines for the EFR32
AN1162: Using the Manufacturing Library for EmberZNet
AN1046: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v2.x
AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x
UG409: RAILtest User’s Guide
AN1019: Using the NodeTest Application
AN961: Bringing Up Custom Devices for the EFR32MG and EFR32FG Families
KBAs
How to build and use the StandardizedRfTesting sample in EmberZnet SDK?
Implementing wireless direct test mode (DTM)
[7] Other
How do I determine the PCB and schematic version of kit boards?
BRD4001A WSTK dimension
Hardware Design Review submission expectations for EFR32MGxx based designs
What are the valid values for txPower?
How to find schematics and other documentation for radio boards?
Six Hidden Costs in a Wireless SoC Design
Master Wireless Hardware KBA list for EFR32 Series 1 SoCs and Wireless Modules
This Knowledge Base Article (KBA) aims to organize all Wireless Hardware related technical documents and related individual KBAs for EFR32 Series 1 SoCs and Wireless modules together in one place.
The KBA organizes all technical documents into categories for a better and convenient way to refer to the contents while designing a custom application based on these parts. The categorized RF hardware contents are as follows:-
[A] EFR32 Series 1 Wireless Modules:
Application Notes:
Knowledge Base Articles:
[B] EFR32 Series 1 Wireless SOCs:
[1] Matching Networks
Application Notes:
Knowledge Base Articles:
[2] RF
Application Notes:
Knowledge Base Articles:
[3] Antenna
Application Notes:
Knowledge Base Articles:
[4] MCU, Power Supply and Peripherals
Application Notes:
Knowledge Base Articles:
[6] Antenna Diversity
Knowledge Base Articles:
[7] General
Application Notes:
Knowledge Base Articles:
Where can I find BSDL file for EFR32 Wireless Gecko devices?
Ways to tell ZigBee nodes to leave the network.
HA Sample Switch won't sleep correctly with EmberZNet 5.7.3 using EFR32 on WSTK
Peripheral utilization on EFR32MG by EmberZNet stack
Question
What peripherals on EFR32MG is the EmberZNet stack using?
Answer
Minimum Requirements
Minimum requirements for proper EmberZNet stack operation are the following:
Additional Resource Usage
These MCU peripherals may be needed by EmberZNet HAL, or Application Framework, or bootloader under certain use cases.
GPIOs used for the pre-built EFR32MG NCP images
EM3xx 24MHz Crystal Tuning
For proper operation of the EM3xx RF block, it is very important to minimize transmit frequency offset, as well as comply with the 802.15.4 specification of +/-40ppm. The frequency offset is adjusted through the txtone (carrier tone) transmit function, as the 24MHz main clock offset directly relates to the transmitter frequency offset.
Use a spectrum analyzer to measure the frequency offset of the carrier. Set the amplitude reference level higher than the expected output power of the device in order to avoid possible damage to test equipment. For ceramic balun designs, this would be +10dBm, while for PA designs +30dBm should work fine as an initial setting and can be adjusted according to the actual PA TX power maximum capability. Configure the radio to transmit a continuous unmodulated tone at 2445MHz by issuing the commands ‘setchannel 13’ and ‘txtone’ with the nodetest application installed on the device. Measure the frequency offset by selecting the frequency counter setting on the spectrum analyzer followed by a marker peak search. To determine the PPM of the frequency offset, use the following equation:
Channel offset PPM = (expected / (measured – expected)) * 1E6
The frequency offset needs to be improved by adjusting the crystal loading caps only if it appears it will not comply with the +/- 40 PPM 802.15.4 specification. The intent is to tune the frequency to be as close to the desired frequency as possible. Refer to AN700 section 2.6, Transmit Frequency test and KBA article EM35xx-24MHz Crystal Selection for additional information.
AN700.0: Manufacturing Test Guidelines for the EM35x
EM35x - Using Software to Measure VDD_PADS