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.768 kHz 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, and devices that advertise most of the time (such as iBeacon or Google Eddystone devices).

Selecting the PLFRCO#

Using the PLFRCO requires a few changes in init_mcu.c and one change in the Bluetooth stack configuration structure.

In the Bluetooth stack configuration structure, change the sleep clock accuracy to 500 ppm.

static gecko_configuration_t config = {
    ...
    ...
    .bluetooth.sleep_clock_accuracy = 500, // ppm
    ...
    ...
};

In init_mcu.c, 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 because you're 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. As a result, the slave must be listening (in RX) to avoid losing the 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. As a result, the RX receive window is longer when using a PLFRCO compared to the LFXO. 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 the RX window extension compared to the LFXO usage.

Figure 3. Empty packet using LFXO

Figure 4. Empty packet using PLFRCO

Note that when the slave misses connection intervals (e.g., if the device was temporarily out of range or because of interference), the RX receive window is widened by the combined accuracy until the slave is able to catch the initial packet from the master. 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.