What relations should be kept between the different VDD rails of EFR32 for proper operation?
The following power supply restrictions need to be followed on the EFR32 devices:
• VREGVDD must be the highest voltage in the system for EFR32.
• VREGVDD = AVDD
• DVDD <= AVDD
• IOVDD <= AVDD
• RFVDD <= AVDD
• PAVDD <= AVDD
• DVDD > DECOUPLE
These relations above are strongly recommended to be followed for proper operation of EFR32 wireless gecko, and mainly due to the internal ESD diode structures and operation conditions.
What's the minimal BOM filtering for the EFR32 Wireless Gecko?
Silicon Labs reference radio board designs typically use an extensive number of components for RF and VDD filtering to achieve the best possible RF performance at even the highest output power levels. However, a number of these elements can be eliminated from the design while still maintaining an acceptable RF performance.
Minimal BOM VDD rail filtering:
- VREGVDD: 100nF; 10uF
- AVDD: 10nF; 10uF
- DVDD: 100nF
- IOVDD: 1uF
- DECOUPLE: 1uF
- RFVDD: 220nF
- PAVDD: 220nF
Depending on the RF carrier frequency the following additional filtering capacitors are recommended to be added to the RFVDD and PAVDD nets:
- 10pF for the 2.4GHz applications
- 56-100pF at the high bands below 1GHz (868-915MHz, typically)
- 220-470pF at the lower sub-GHz bands (169-470MHz)
In the case of having the PA-, RF- and DVDD rails run from the internal on-chip DC-DC converter, the following series inductors (or ferrites) need to be added:
- 22nH on PAVDD at 2.4GHz
- 100-120nH on PA-, and RFVDD at the higher sub-GHz bands
- 220-470nH on PA-, and RFVDD at the lower sub-GHz bands
Additional details can be found in "AN933: EFR32 Minimal BOM" application note.
Where can I find EFR32 reference designs?
The EFR32 kit radio boards serve as the base reference designs. These can be found in a few locations:
Design source (schematic and layout) may be available upon request. Silicon Labs is working to provide these in the locations mentioned above in the near future.
Other EFR32 reference designs, like IoT Solutions product-specific reference designs, can be found here.
How can I implement antenna diversity for EFR32MG?
Silicon Labs does not specifically have an antenna diversity reference design for EFR32MG. However, you can reference the EM35x antenna diversity design for an example of external RF switch that could be used. As of the EmberZNet 5.7.4 stack release, transmit/software diversity (switching antenna path when MAC-level Ack is not received) is available in the EmberZNet stack and any GPIO(s) can be used for this antenna select function, based on selection via the Antenna plug-in. Receive/hardware diversity (assessment of RSSI on incoming packet to select strongest path) is not supported. That being said, GPIO selection per MODEM_ANT0 and MODEM_ANT1 (in the case of a 2nd antenna select GPIO, as with an external RF switch) in your design will ensure that transmit/software diversity can be used in the short term, with a software upgrade to receive/hardware diversity at a later date, if available. See EFR32MG1 datasheet Table 6.7 for details on GPIOs available for the MODEM_ANT0 and MODEM_ANT1 functions.
In terms of hardware-level recommendations, the antennas should be separated by at least 1/4 lamba distance and should be rotated 90 degrees from one another. Please reference the EM35x antenna diversity design noted above for an example of this.
How do I use the CTUNE token for EFR32?
The EFR32 38.4MHz crystal does not require external loading caps, as there is a tunable capacitor bank in the EFR32 that can be used instead. Different tune values can be written to registers to observe the corresponding frequency offset, and the CTUNE token is used to store the value for use by the application. Here in this example, we refer to nodetest commands.
Once your EFR32 device is programmed with nodetest, if you enter “tokdump” you should see the ctune token amongst the tokens reported:
[C354] MFG_CTUNE FF FF
Note that there are also nodetest commands "setCtune" and "getCtune" where you can set and read the CTUNE register values. This is helpful if you want to try multiple specific ctune values and measure their affect prior to writing the token. From the nodetest "help" output:
setCtune u4 - set CTUNE registers (CMU->HFXOSTEADYSTATECTRL_CTUNE and CMU->HFXOSTARTUPCTRL_CTUNE)
getCtune - get CTUNE register value
A default / erased value for MFG_CTUNE corresponds to using the nodetest default ctune register value of 0x142. The EFR32 reference manual provides a formula for ctune:
Sets oscillator tuning capacitance.
Capacitance on HFXTAL_N and HFXTAL_P (pF) = Ctune = Cpar + CTUNE<8:0> x 40fF.
Max Ctune 25pF (CLmax ~12.5pF)
CL(DNLmax)=50fF ~ 0.6ppm (12.5ppm/pF)
With this calculation, the default of 0x142 (322 decimal) and no loading caps installed (as is the case with the BRD4151A modules in the WSTK) corresponds to a capacitance of 12.8pF.
You can issue the nodetest command "tokWrite c354" to write this token:
tokWrite u2 - Write all data of a token (u2=creator code)
Similar set/get of CTUNE register values can be achieved with RAIL test as well. See the RAIL test user documentation for additional details.
Setting CTUNE token can also be achieved via Simplicity Commander. See the Simplicity Commander User Guide UG162 for additional details on setting tokens.
What is the optimum load impedance for EFR32 wireless gecko at 2.4GHz?
The optimum termination impedance is determined by load-pull measurements at the 2.4GHz frequency band. The optimum load impedance yields the best TX power efficiency, while the RX performance is also close to its optimum.
The EFR32 has a single-ended 2.4GHz RF pin for TX and RX (2G4RF_IOP). The other pin, 2G4RF_ION, has to be tied to the GND and cannot be interchangeable with 2G4RF_IOP.
The 2G4RF_IOP pin does not need to be pulled up to the VDD, since the 2.4GHz PA is supplied from a separate PAVDD pin, moreover the RF pin is DC-grounded.
The optimum termination impedance at the single-ended 2G4RF_IOP pin is 23+j11.5 ohms in the whole 2.4GHz ISM band for higher than +10dBm power output. For lower output power levels this optimum impedance is 20+j10.6 ohms.
Details are in AN930 application note.
The on board voltage regulator lends itself for use in powering more than just certain power pins on the EFR32 itself. Typically the DC-DC is recommended for powering the EFR32 RFVDD, DVDD and sometimes the PAVDD power pins (for desired transmit power levels 13 dBm and lower). There may also be custom applications where it is appropriate to use the DC-DC regulated output for powering additional EFR32 power supply pins or even other device power pins. In cases where the DC-DC is to be used for powering peripherals and / or the IOVDD supply, the designer should:
Note that all validation testing has been at 1.8V and therefore datasheet parameters may be different for DC-DC outputs other than 1.8 V.
If one of the peripheral devices is also an EFR32, do not power that EFR32’s DVDD pin, due to DVDD will short to AVDD internally upon exiting reset and cause a potential over-current situation for the source DC-DC.
For additional information about the EFR32 DC-DC, please review the application note AN948.
When done, Silicon Labs recommends you submit your finalized design for review in the customer portal.
How do I connect a TCXO to an EFR32?
A TCXO clock source can be used to supply the EFR32 main clock. Reconfiguration of the HFXO register settings in the Clock Management Unit will be required for operation with a TCXO. Consult the EFR32 Reference Manual for additional details regarding the following settings:
Be sure to physically connect the TCXO to the HFXTAL_N pin for the above register settings. The HFXTAL_P pin should be no-connect.
Are all EFR32 parts of the same package variant pin-compatible?
No. The pin-outs are dependent on frequency band: Sub-G Band, 2.4G Band, and dual-band (Sub-GHz and 2.4GHz). Using EFR32FG1 QFN48 as an example, per the datasheet (http://www.silabs.com/Support%20Documents/TechnicalDocs/EFR32FG1-DataSheet.pdf) section 6 shows the pin definitions per package type and variant. Figure 6.1 shows the QFN48 sub-GHz pin-out, Figure 6.2 shows the QFN48 2.4GHz pin-out, and Figure 6.3 shows the QFN48 dual-band pin-out. All 3 pin-outs differ for pin function of pin numbers 13 through 21. And other pins' definitions are the same. The pin definition differences are listed as below:
|Pin No.||Sub-G Band||2.4G Band||Dual Band|