KBA_BT_0409: Using the PLFRCO as low-frequency clock source
06/169/2019 | 11:59 AM
Introduction
The EFR32xG13 devices (revision D or newer) include an internal oscillator, the PLFRCO, or Precision Low Frequency RC Oscillator, which is a self-calibrating RC oscillator that eliminates the need for a 32.768kHz crystal.
The PLFRCO can be used by the Bluetooth stack as the low frequency clock source (instead of the LFXO) that is used by the system to wake-up the device on each connection interval when sleep is enabled in the stack.
The PLFRCO has a frequency accuracy of +/-500 ppm which is within the Bluetooth specification requirements.
It is best suited for some BLE use cases such as applications with very constrained cost targets or board layout space, devices that maintain short connection intervals or have infrequent BLE connections as well as devices that advertise most of the time (such as iBeacon or Google Eddystone devices).
Selecting the PLFRCO
Using the PLFRCO requires only a few changes in init_mcu.c and one change in the Bluetooth stack configuration structure.
In the Bluetooth stack configuration structure the sleep clock accuracy needs to be changed to 500 ppm.
In init_mcu.c it is required to initialize the PLFRCO and select it as a clock source for the low frequency clock branches. There’s essentially 2 steps to take:
Remove the LFXO related initialization code
Uncomment PLFRCO related code to change clock sources LFA, LFB, LFE and init oscillator
// UNCOMMENT THIS >>
//To use PLFRCO please remove commenting of these lines
//and comment out or delete the LFXO lines if they are present
//If using PLFRCO update gecko_configuration_t config's
//.bluetooth.sleep_clock_accuracy to 500 (ppm)
// #if defined(PLFRCO_PRESENT)
// /* Ensure LE modules are accessible */
// CMU_ClockEnable(cmuClock_CORELE, true);
// /* Enable PLFRCO as LFECLK in CMU (will also enable oscillator if not enabled) */
// CMU_ClockSelectSet(cmuClock_LFA, cmuSelect_PLFRCO);
// CMU_ClockSelectSet(cmuClock_LFB, cmuSelect_PLFRCO);
// CMU_ClockSelectSet(cmuClock_LFE, cmuSelect_PLFRCO);
// #endif
// DELETE OR UNCOMMENT THIS >>
// Initialize LFXO
CMU_LFXOInit_TypeDef lfxoInit = BSP_CLK_LFXO_INIT;
lfxoInit.ctune = BSP_CLK_LFXO_CTUNE;
CMU_LFXOInit(&lfxoInit);
// Set system LFXO frequency
SystemLFXOClockSet(BSP_CLK_LFXO_FREQ);
// Set LFXO if selected as LFCLK
CMU_ClockSelectSet(cmuClock_LFA, cmuSelect_LFXO);
CMU_ClockSelectSet(cmuClock_LFB, cmuSelect_LFXO);
CMU_ClockSelectSet(cmuClock_LFE, cmuSelect_LFXO);
Tradeoffs
The most obvious benefit of using the PLFRCO instead of the LFXO is the cost savings from not using the low frequency crystal. The drawback is that the PLFRCO increases the sleep current by up to 500 nA and extends the RX receive window on the slave side at the beginning of each connection interval.
Sleep Current
Below are sleep current measurements on the same device with LFXO and PLFRCO where the sleep current difference is about 280 nA.
Figure 1. EFR32xG13 sleep current with LFXO
Figure 2. EFR32xG13 sleep current with PLFRCO
RX Period Extension
At the beginning of each connection interval the master device is the first to send out a packet. This makes it a hard requirement that the slave must be listening (in RX) in order not to lose that initial packet from the master device. The combined clock accuracy from master and slave (sum of both accuracy values in ppm) is used to calculate when the slave should wake-up to listen for the incoming packet.
When the accuracy is lower, the slave must wake-up earlier, so there will be a longer RX receive window when using a PLFRCO compared to the LFXO due to the lower accuracy. The images below show an empty packet taken from the slave side with 1 second connection interval and 0 dBm output power. When using PLFRCO the RX receive window is extended by ~250 µs. The longer the connection intervals the more pronounced will be the RX window extension when compared to LFXO usage.
Figure 3. Empty packet using LFXO
Figure 4. Empty packet using PLFRCO
One final note, when the slave misses connection intervals (e.g. device was temporarily out of range or due to interference) then the RX receive window will be widened by the combined accuracy until the slave is able to catch the initial packet from the master. Let's consider a combined accuracy of +/-600 ppm. If the connection interval is 1 s and the slave misses a connection interval, the next interval's RX receive window will be widened by 600 µs = 600 parts of 1 million micro-seconds.
KBA_BT_0409: Using the PLFRCO as low-frequency clock source
Introduction
The EFR32xG13 devices (revision D or newer) include an internal oscillator, the PLFRCO, or Precision Low Frequency RC Oscillator, which is a self-calibrating RC oscillator that eliminates the need for a 32.768kHz crystal.
The PLFRCO can be used by the Bluetooth stack as the low frequency clock source (instead of the LFXO) that is used by the system to wake-up the device on each connection interval when sleep is enabled in the stack.
The PLFRCO has a frequency accuracy of +/-500 ppm which is within the Bluetooth specification requirements.
It is best suited for some BLE use cases such as applications with very constrained cost targets or board layout space, devices that maintain short connection intervals or have infrequent BLE connections as well as devices that advertise most of the time (such as iBeacon or Google Eddystone devices).
Selecting the PLFRCO
Using the PLFRCO requires only a few changes in init_mcu.c and one change in the Bluetooth stack configuration structure.
In the Bluetooth stack configuration structure the sleep clock accuracy needs to be changed to 500 ppm.
In init_mcu.c it is required to initialize the PLFRCO and select it as a clock source for the low frequency clock branches. There’s essentially 2 steps to take:
Tradeoffs
The most obvious benefit of using the PLFRCO instead of the LFXO is the cost savings from not using the low frequency crystal. The drawback is that the PLFRCO increases the sleep current by up to 500 nA and extends the RX receive window on the slave side at the beginning of each connection interval.
Sleep Current
Below are sleep current measurements on the same device with LFXO and PLFRCO where the sleep current difference is about 280 nA.
Figure 1. EFR32xG13 sleep current with LFXO
Figure 2. EFR32xG13 sleep current with PLFRCO
RX Period Extension
At the beginning of each connection interval the master device is the first to send out a packet. This makes it a hard requirement that the slave must be listening (in RX) in order not to lose that initial packet from the master device. The combined clock accuracy from master and slave (sum of both accuracy values in ppm) is used to calculate when the slave should wake-up to listen for the incoming packet.
When the accuracy is lower, the slave must wake-up earlier, so there will be a longer RX receive window when using a PLFRCO compared to the LFXO due to the lower accuracy. The images below show an empty packet taken from the slave side with 1 second connection interval and 0 dBm output power. When using PLFRCO the RX receive window is extended by ~250 µs. The longer the connection intervals the more pronounced will be the RX window extension when compared to LFXO usage.
Figure 3. Empty packet using LFXO
Figure 4. Empty packet using PLFRCO
One final note, when the slave misses connection intervals (e.g. device was temporarily out of range or due to interference) then the RX receive window will be widened by the combined accuracy until the slave is able to catch the initial packet from the master. Let's consider a combined accuracy of +/-600 ppm. If the connection interval is 1 s and the slave misses a connection interval, the next interval's RX receive window will be widened by 600 µs = 600 parts of 1 million micro-seconds.
Will this work on this MCU: