AN0004.1: EFM32 Series 1 and EFR32 Wireless MCU Clock Management Unit (CMU)

2.3.3 HFRCO, AUXHFRCO, and USHFRCO

The HFRCO, AUXHFRCO, and USHFRCO (available on Giant Gecko Series 1 only) default to operation in the 19 MHz band but can be switched to operate in one of the other preset frequency bands by changing the FREQRANGE bit field in the CMU_HFRCOCTRL, CMU_AUXHFRCOCTRL, or CMU_USHFRCOCTRL registers. The USHFRCO (Universal HFRCO) is functionally identical to the AUXHFRCO and can provide the clock for the QSPI, SDIO, or USB independent of the HFSRCCLK.

Table 2.7. High Frequency RC Oscillator Band Selection

The specific values that select each tuning band are written to the TUNING bit field in the CMU_HFRCOCTRL and CMU_AUXHFRCOCTRL registers. Each band is calibrated during production, with suitable tuning values written to the Device Information (DI) page.

The HFRCO and AUXHFRCO frequency can be more accurately tuned at the cost of increased current consumption via the FINETUNING and FINETUNINGEN bit fields in the CMU_HFRCOCTRL and CMU_AUXHFRCOCTRL registers.

When Voltage Scaling is used (not available on EFM32xG1 and EFR32xG1 devices), the HFRCO and AUXHFRCO must be tuned to frequencies that do not exceed the maximum system frequency permitted with scaling before voltage scaling is actually applied.

Emlib has specific functions to change the frequency band to which the AUXHFRCO and HFRCO are tuned. Use of emlib is strongly recommended because it specifically handles the need to increase the number of flash wait states or voltage scaling when a higher frequency tuning band is selected. These functions switch to the desired frequency band by loading the correct tuning value from the Device Information (DI) page.

Table 2.8. emlib Functions for Changing the AUXHFRCO and HFRCO Tuning Bands

2.3.4 LFRCO

It is possible to calibrate the LFRCO to achieve higher accuracy. The frequency is adjusted by changing the TUNING bit field in the CMU_LFRCOCTRL register. The LFRCO is also calibrated in production, and its default TUNING value is set during reset.

Voltage reference duty cycling can be enabled for the LFRCO by setting the ENVREF bit in the CMU_LFRCOCTRL register before enabling the LFRCO. This reduces current consumption at the expense of slightly worse frequency accuracy, especially at high temperatures. Comparator chopping and dynamic element matching are enabled with the ENCHOP and ENDEM bits in the CMU_LFRCOCTRL register, which improves the average LFRCO frequency accuracy at the cost of reduced cycle-to-cycle accuracy (increased jitter).

2.3.5 ULFRCO

The ULFRCO is always on in EM0, EM1, EM2, EM3 and EM4H and cannot be disabled via the CMU_OSCENCMD register. As such, it is always available as a clock source for many of the peripherals in the low-frequency clock domains. It is not possible to calibrate the ULFRCO to achieve higher accuracy.

2.4 Oscillator Start-Up Time and Time-Out

The start-up time for each of the previously discussed oscillators differs and, in certain cases, can be further extended by one or more programmable time-out delays. When enabled, the oscillator's output is given time to stabilize by stalling assertion of its ready signal for the specified number of clock cycles. Low start-up times can be selected when the clock is coming from a high quality source, while longer time-out delays are necessary when the clock is coming directly from a crystal.

Programmable time-outs are available for the LFXO, HFXO, and LFRCO. The HFRCO, AUXHFRCO, ULFRCO, and USHFRCO time-out delays are fixed and cannot be changed.

Table 2.9. Oscillator Time-Out Configuraton

2.4.1 HFXO Deterministic Start-up Time

A second time-out counter allows the HFXO to achieve deterministic start-up timing based on the LFXO, ULFRCO, or LFRCO. It runs off the LFECLK and can even be used during wake-up from EM2 when either the ULFRCO, LFRCO, or LFXO is already running and stable (see 5.2.3 Automatic HFXO Start with Deterministic Start-Up).

When enabled, this counter delays HFXO ready assertion by the number of LFECLK cycles specified by the LFTIMEOUT bit field in the CMU_HFXOCTRL register. The HFXO ready signal is asserted when the time-out counters configured via the CMU_HFXOTIMEOUTCTRL register and the LFTIMEOUT counter have both elapsed. If the LFTIMEOUT countdown completes first, the LFTIMEOUTERR bit in CMU_IF will be set. Note that use of LFTIMEOUT requires the peripheral causing the wake-up from EM2 to reside in the LFECLK domain.

2.5 Prescaling

Each of the clock sub-branches derived from the HFCLK, such as the HFCORECLK, HFBUSCLK, and HFPERCLK, can be individually prescaled by a factor of 1 to 512, while the HFCLK itself can be divided down by a value between 1 and 32. The HFCORECLK drives the CPU and modules tightly coupled to it like the flash (MSC) and SRAM. The HFBUSCLK does the same for modules which can read and write data on their own like the LDMA and USB but also for modules requiring fast response to CPU reads and writes, such as the GPIO and external bus interface (EBI). The HFPERCLK and its branches (HFPERBCLK and HFPERCCLK) drive high-frequency peripherals like the timers and USARTs. Some peripherals permit further clock prescaling (such as the ADC), which is controlled independently in each such peripheral's register space.

Prescaling is controlled independently by dedicated bit fields for most peripherals in the low frequency clock domains (LFA, LFB, and LFE), with the exception of the Pulse Counter (PCNT).

Table 2.10. Prescaler of Clock Branches

Note: 1. Not all prescaler bitfields are available on a given device. Refer to the device reference manual and data sheet for details.

Emlib has functions to set the clock prescalers, and its use is highly encouraged because synchronization is required for prescalers in the low frequency clock domains.

Table 2.11. emlib Clock Divider and Prescaler Functions

When using these functions, careful consideration is required for both parameters. Not all clocks have a prescaler, and the maximum prescaling value is also not the same for the different clocks (HFPERCLK, for instance, has a maximum of 512 while the LETIMER clocks can be divided by 32768).

2.6 Flash Wait States

When increasing the memory subsystem clock (HFCLK) frequency above certain limits, the number of wait states required for flash read accesses must be increased before the frequency change is performed. Likewise, the number of wait states can be reduced when the HFCLK frequency falls below certain limits, and this must be performed after the frequency change has taken place. Wait state and frequency changes are properly sequenced and handled automatically by emlib's CMU functions, and their use is strongly encouraged. Changes to the number of wait states can be made under user control directly by writing to the MODE bit field in the MSC_READCTRL register.

Table 2.12. Flash Wait States for EFM32xG1 and EFR32xG1

Table 2.13. Flash Wait States for EFM32xG12/13 and EFR32xG12/13

Table 2.14. Flash Wait States for Giant Gecko Series 1

Voltage scaling (not supported on EFM32xG1 and EFR32xG1 devices) allows for a tradeoff between power and performance. The flash wait states for voltage scaling level 0 are described in table below. Operation above 21 MHz with voltage scaling is not supported.

Table 2.15. Flash Wait States at Voltage Scaling Level 0

The emlib functions below optimize flash access wait-state configuration if the source or frequency of HFCLK is changed when invoking these functions.

• CMU_ClockDivSet(CMU_Clock_TypeDef clock, CMU_ClkDiv_TypeDef div)
• CMU_ClockPrescSet(CMU_Clock_TypeDef clock, CMU_ClkPresc_TypeDef presc)
• CMU_ClockSelectSet(CMU_Clock_TypeDef clock, CMU_Select_TypeDef ref)
• CMU_HFRCOBandSet(CMU_HFRCOFreq_TypeDef setFreq)
• CMU_HFXOAutostartEnable(uint32_t userSel, bool enEM0EM1Start, bool enEM0EM1StartSel)

2.7 Low Energy (LE) Peripheral Clock Divider

To use the low energy peripheral modules, the LE interface clock (HFCLKLE) must be enabled in addition to the module clock.

The HFCLKLEPRESC bitfield in the CMU_HFPRESC register is used to divide the HFBUSCLKLE frequency to ensure the HFCLKLE frequency is within the limit.

The WSHFLE bitfield in the CMU_CTRL register is used to ensure that the Low Energy Peripheral Interface is able to operate at the given HFBUSCLKLE frequency by inserting wait states when using this interface.

Table 2.16. Low Energy Peripheral Clock Divider

Before going to a high frequency, make sure the registers in the table above have the correct values. When going down in frequency, make sure to keep the registers at the values required by the higher frequency until after the switch completes.

To make this task easier, there is also a function available in the emlib to ensure the registers in the table above have the correct values when enabling the LE clock.

Table 2.17. The emlib Function to Enable a Module Clock

2.8 External Clock Sources

By default, the LFXO and HFXO are started in crystal mode, but it is possible to connect an active external sine wave or square wave clock source to the LFXTAL_N and HFXTAL_N pins of the LFXO and HFXO as discussed in the following sections.

2.8.1 External Sine Wave

An AC-coupled, externally buffered sine wave can be applied to the HFXTAL_N or LFXTAL_N pin. The amplitude of this signal must be at least 0.8 V peak-to-peak, and the frequency is subject to the same limit as that of a crystal connected to the HFXO or LFXO.

Each oscillator has a way to be configured for use with a stimulus other than a crystal. In the case of the HFXO, the MODE bit in the CMU_HFXOCTRL register is set to indicate that an external clock source (EXTCLK) is being used. Sine wave operation for the LFXO is selected by the BUFEXTCLK setting of the CMU_LFXOCTRL register's MODE bit field.

2.8.2 Digital External Clock

A rail-to-rail square wave with 50% duty cycle can be applied to the HFXTAL_N or LFXTAL_N pin, subject to the same frequency limit as that of a crystal connected to the HFXO or LFXO.

Each oscillator has a way to be configured for use with a stimulus other than a crystal. In the case of the HFXO, the MODE bit in the CMU_HFXOCTRL register is set to indicate that an external clock source (EXTCLK) is being used. Operation with a digital external clock for the LFXO is selected by the DIGEXTCLK setting of the CMU_LFXOCTRL register's MODE bit field.

2.8.3 Oscillator Pin Availability

When a clock is supplied via LFXTAL_N, the corresponding LFXTAL_P pin is not needed and can be used for GPIO or peripheral functionality. HFXTAL_P availability when not used to connect a crystal is device-dependent and can be found in the datasheet pin alternate functionality tables.

2.9 Output Clock to Pin

The CMU can drive user-specified clocks on certain pins. Selection is done using the CLKOUTSELn bit fields in the CMU_CTRL register. It is also necessary to (a) select which pins are driven in the CMU_ROUTELOC0 register, (b) configure them as outputs in the appropriate GPIO pin mode registers, and (c) enable each one via its corresponding bit in the CMU_ROUTEPEN register.

Note that a clock sourced from an oscillator (e.g. the HFXO) can be unstable after startup and should not be output on a pin before its corresponding ready flag (e.g. HFXORDY) is set in the CMU_STATUS register.

Table 2.18. Clock Output on a Pin

Table 2.19. Pin Use for HFXO Start-Up Demo

Note: 1. Giant Gecko Series 1 only

2.10 Clock Output to PRS

The CMU can be used as a PRS producer with the clocks selected by the CLKOUTSEL bit fields in the CMU_CTRL register directed to any of the PRS consumers.

Other than picking the clock(s) desired via the CLKOUTSEL bit field(s), no additional configuration of the CMU is required. Instead, a given PRS channel routes one of the CMU clock outputs to a consumer via the SOURCESEL and SIGSEL fields in the PRS_CHx_CTRL register.

Apart from its typical uses (e.g. for ADC conversion start timing), the PRS can be used as an enhanced clock output routing mechanism. Depending on the device, each PRS channel can be output to anywhere between 3 and 17 different pins, making it possible to route the different CMU clock outputs to pins not otherwise made available via location bit fields in the CMU_ROUTELOC0 register.

2.11 Interrupts

The CMU can request interrupts from multiple sources that are serviced by a single interrupt vector. If CMU interrupts are enabled, an interrupt is requested when one or more of the flags in CMU_IF register and their corresponding bits in CMU_IEN register are set.

The LFRCORDY and LFXORDY interrupts can be used to wake from EM2. In this way, waiting for either the LFRCO or LFXO to stabilize by polling its associated ready bit can be avoided by going into EM2 after enabling the oscillator and sleeping until the ready interrupt causes a wake-up.

2.12 Automatic HFXO Start

EFM32 and EFR32 Wireless Gecko Series 1 devices can enable the HFXO and select it as the HFSRCCLK automatically under hardware control. This is intended to minimize current draw by allowing the system to remain in a low-energy mode until the HFXO is ready instead of having software poll the HFXORDY bit in the CMU_STATUS or CMU_IF register.

The AUTOSTARTRDYSELRAC bit in the HFXOCTRL register on the EFR32 Wireless Gecko Series 1 family permits automatic HFXO start-up and its selection as the HFSRCCLK when ready in response to the wake-up event from the Radio Controller (RAC). The CMU documentation for these devices describes a typical use case whereby the RAC (which must run from the HFXO) periodically wakes from EM2 to perform work and then goes back to sleep all without software intervention courtesy of this feature.

A separate mechanism controlled by the AUTOSTARTSELEM0EM1 and AUTOSTARTEM0EM1 bits in the CMU_HFXOCTRL register performs a similar function depending on the current energy mode.

Table 2.19. Energy Mode-Dependent HFXO Start-up and HFSRCCLK Selection

When AUTOSTARTSELEM0EM1 is set to 1 in EM0/EM1 (regardless of the state of the AUTOSTARTRDYSELRAC or AUTOSTARTEM0EM1 bits), selection of the HFXO as the HFSRCCLK will occur immediately, even if HFXO is not yet ready. Upon wake-up into EM0/EM1, this can therefore lead to a relatively long start-up time as the system will not operate from the HFRCO as it would otherwise normally do (see 5.2.2 Automatic HFXO Start with Normal Start-Up and 5.2.3 Automatic HFXO Start with Deterministic Start-Up).

Care should be taken to ensure that the settings of the MSC_READCTRL (flash wait states) and CMU_CTRL (WSHFLE) registers are compatible with the HFXO frequency before enabling the automatic start-up feature. This is properly handled when HFXO auto-start is enabled using the emlib CMU_HFXOAutostartEnable() function.

2.13 Digital Phased-Locked Loop (DPLL)

The Digital Phase-Locked Loop (DPLL) uses a digitally controlled oscillator (DCO) and 12-bit N and M dividers as part of a feedback mechanism that allows more accurate tuning of the HFRCO clock output.

Note: EFR32 Wireless Gecko Series 1 and EFM32xG1 devices do not include the DPLL.

Table 2.20. Digital Phase-Locked Loop Operation

3. Energy Modes

3.1 Active Oscillators

The energy mode of the device determines which oscillators are active. In EM0 and EM1, all oscillators can be enabled and used as clock sources. Upon entering EM2, the high frequency oscillators (HFXO, HFRCO, AUXHFRCO, and USHFRCO, if present) shut off automatically, such that the high frequency peripherals running from them are also effectively shutdown. In EM3, the low frequency oscillators (LFXO and LFRCO if present) also stop, disabling the low frequency peripherals. The ULFRCO is active in all energy modes down to EM4H and is only disabled in EM4S unless explicitly retained via the RETAINULFRCO bit in the EMU_EM4CTRL register.

Table 3.1. Energy Mode Oscillator Availability

Note:
1. In response to an asynchronous ADC trigger from the PRS.
2. If retained by the RETAINLFXO bit in EMU_EM4CTRL.
3. If retained by the RETAINLFRCO bit in EMU_EM4CTRL.
4. If retained by the RETAINULFRCO bit in EMU_EM4CTRL.

3.2 Wake Up Considerations

3.2.1 Waking up from Low-Energy Modes

All the oscillators are able to run in EM1, so the core wakes up instantly from this energy mode. In EM2 and EM3 the high frequency oscillators are disabled, and these need to be re-enabled before the core starts running code.

When waking up from EM2 or EM3, the core will run from the HFRCO by default, regardless of which oscillator it was running from before entering these energy modes. The HFRCO has a very short wake-up time, and it takes only few microseconds before the CPU starts running code. The previously-selected HFRCO band is also restored by hardware on wake-up. The core will run the HFRCO at the default frequency band when waking up from EM4H or EM4S.

Note: Refer to the device-specific data sheet for the wake-up times from each energy mode.

3.2.2 Restoring the Oscillator

To use an oscillator other than the HFRCO after wake-up from a low-energy mode, the user must either enable and select the oscillator manually or use the energy mode entry functions in emlib, like EMU_EnterEM2(), which can handle this automatically.

If an oscillator (the HFXO, for instance) is manually selected as a clock source before it is stable, the system may not operate correctly. The EMU_EnterEM2() and EMU_EnterEM3() functions in emlib have a boolean parameter that permits any previously enabled oscillators to be restored upon wake-up (see figure below).

When the user chooses not to restore previously enabled oscillators upon low-energy mode wake-up, any oscillator, other than the HFRCO, that is needed must be manually enabled and selected as a clock source. When the EMU_EnterEM2() or EMU_EnterEM3() boolean restore parameter is true, emlib will re-enable oscillators, wait for the previously selected HFCLK source to stabilize, and re-select it as the HFCLK at the expense of additional processing time upon wake-up. If the HFRCO was disabled prior to low-energy mode entry (e.g. the HFCLK was sourced from the HFXO), emlib will also disable it after restoring the previously selected HFCLK source.

If restore is false:

• HFCLK will be HFRCO
• Processing time is proportional to wake up time

If restore is true:

• HFCLK will be the same prior to EM2/3
• Processing time is proportional to start-up time and inversely proportional to oscillator speed

The LFXO and HFXO have programmable start-up delays that are set in software by bit fields in each oscillator's respective control registers (see Table 2.9 Oscillator Time-Out Configuraton on page 15). These bit fields specify the number of cycles that must elapse before the oscillator's ready flag is set and can be adjusted to match the characteristics of a particular crystal (faster or slower start-up). A longer time-out (e.g. 16K cycles) guarantees oscillator stability but also extends the period after wake-up spent polling the oscillator's ready flag. For a 32 MHz crystal, a time-out of 16K translates into an approximate delay of 500 µs between the HFXO starting up and its ready flag being set. A lower time-out results in the ready flag setting sooner, but with the risk that the oscillator might not yet be stable.

Each oscillator's ready flag can also be enabled as an interrupt request, the benefit of which is that the processor can continue running code after enabling an oscillator without the need for polling. This is particularly useful when the HFXO provides the HFCLK. Instead of using the EMU_EnterEM2() or EMU_EnterEM3() restore capability, the HFXO ready interrupt can be enabled prior to entering EM2 or EM3. Upon wake-up, software can manually restart the HFXO and continue running code with the HFCLK still sourced from the HFRCO, only switching to the HFXO when the ready interrupt is eventually requested.

4. RC Oscillator Calibration

The CMU has built-in hardware support to efficiently calibrate the RC oscillators at run-time by comparing the RC oscillator frequency with a selected reference clock. When the calibration circuit is started, one down-counter running from a selectable clock (DOWNSEL bit field in the CMU_CALCTRL register) and one up-counter running from another selectable clock (UPSEL bit field in the CMU_CALCTRL register) are started simultaneously.

When the down-counter has reached 0, the up-counter is sampled and the CALRDY interrupt flag is set. If the CONT bit in the CMU_CALCTRL register is cleared, the counters are stopped after finishing the ongoing calibration. Continuous mode is selected by setting the CONT bit, such that the down-counter reloads its top value and continues counting, and the up-counter restarts from 0. Software can then read the sampled up-counter value from the CMU_CALCNT register.

Table 4.1. The CMU_CALCTRL Register

Note: 1. Giant Gecko Series 1 only

An additional FINETUNING bit field is used to tune the HFRCO and AUXHFRCO frequencies in smaller increments than the TUNING bit field. By default, fine tuning is disabled and the FINETUNING value has no effect. Fine tuning can be enabled by writing 1 to FINETUNINGEN bitfield in the CMU_HFRCOCTRL and CMU_AUXHFRCOCTRL registers.

5. Software Examples

5.1 RC Oscillator Calibration

This example calibrates the RC oscillators against the crystal oscillators (see the table below) and displays the TUNING and FINETUNING values before and after calibration on the LCD.

Table 5.1. Clock Selection for RC Oscillator Calibration

The calibrateRcOsc(CMU_Osc_TypeDef rcOsc, uint32_t rcOscFreq, bool calCont, bool fineEnable) function in the cmu_calibrate.c source file shows how to use the emlib functions for RC oscillator calibration.

Table 5.2. Parameters for calibrateRcOsc() Function

The current TUNING value of the RC oscillator is loaded from the Device Information (DI) page or the TUNING bit field in the corresponding RC oscillator control register. The default down-counter initial value (TOP) is 0xFFFFF for maximum calibration accuracy.

The calibration process is interrupt driven (CMU_IRQHandler() in cmu_calibrate.c), and the TUNING value can either be decremented or incremented in each iteration until the expected value for the up-counter (UPCOUNTDESIRED) is reached.

Then the two last counter values are compared to see which one is closer to the one resulting from the formula, and the TUNING value is adjusted accordingly. The final saved TUNING value is displayed on the LCD, and the endOfTune flag is set to indicate that calibration is finished.

The HFRCO and AUXHFRCO frequencies can be tuned more accurately via the FINETUNING and FINETUNINGEN bit fields in the CMU_HFRCOCTRL and CMU_AUXHFRCOCTRL registers.

When fine tuning is used, the HFRCO and AUXHFRCO frequencies will drift away from their nominal frequencies when the FINETUNINGEN bits in the CMU_HFRCOCTRL and CMU_AUXHFRCOCTRL registers are set to 1 for the first time. This happens because the FINETUNING bit field values are not calibrated during production testing, and a default value of 0x1F is used.

Table 5.3. RC Oscillator Tuning Ranges

Note: 1. Larger values written to the TUNING or FINETUNING bit fields translate into lower frequencies.

If an oscilloscope is available, the RC oscillator output can be observed on one of the Starter Kit (STK) Expansion Header pins, which is configured as a CMU clock output pin during the calibration process. The following table lists the pin to probe on a given STK or wireless STK and radio board combination.

Table 5.4. RC Oscillator Probe Output

This example project uses the naming convention BOARD_cmu_example, where BOARD is one of the STK or radio board part numbers from the table above. A menu screen shows the RC oscillator to be calibrated; BTN0 runs the calibration, and BTN1 cycles through the different RC oscillators.

5.1.1 Calibrate LFRCO with HFXO

When the example code is run to calibrate the LFRCO against the HFXO, the output should look something like the screens shown below.

Press push button BTN1 to select [Example 1: HFXO to Calibrate LFRCO].

Press push button BTN0 to start the LFRCO calibration process. The current LFRCO TUNING value and target up counter are displayed on the memory LCD as shown below.

The final up counter and LFRCO TUNING value are displayed on the memory LCD when LFRCO calibration is complete.

5.1.2 Calibrate HFRCO with LFXO

When the example code is run to calibrate the HFRCO against the LFXO, the output should look something like the screens shown below.

Press push button BTN1 to select the [Example 2: LFXO to Calibrate HFRCO].

Press push button BTN0 to start the HFRCO calibration process. The current HFRCO TUNING value, FINETUNE value, and target up counter are displayed on the memory LCD as shown below.

The final up counter, HFRCO TUNING value, and FINETUNE value are displayed on the memory LCD when HFRCO calibration is complete.

5.1.3 Calibrate AUXHFRCO with LFXO

When the example code is run to calibrate the AUHFRCO against the LFXO, the output should look something like the screens shown below.

Press push button BTN1 to select the [Example 3: LFXO to Calibrate AUXHFRCO].

Press push button BTN0 to start the AUXHFRCO calibration process. The current AUXHFRCO TUNING value, FINETUNE value, and target up counter are displayed on the memory LCD as shown below.

The final up counter, AUXHFRCO TUNING value, and FINETUNE value are displayed on the memory LCD when AUXHFRCO calibration is complete.

5.2 HFXO Start-Up Time

This example illustrates, in particular, when the HFXO is used, the time it takes to wake from EM2 and begin code execution depending upon the selected clock source and start-up mechanism. The LETIMER generates pulses at one second intervals that are routed to a pin. This pin, which can be observed on an oscilloscope, must be connected using a jumper wire to another pin, which, in turn, wakes the system via GPIO interrupts.

When configured to do so, enabling of the HFXO and its selection as the HFSRCCLK source is performed automatically by hardware upon wake-up from EM2. HFXO start-up time can be made deterministic and is programmed via the LFTIMEOUT bit field in the CMU_HFXOCTRL register to be 16 LFECLK cycles (~ 488 µs) in this example.

As noted above, GPIOs can be observed to trace the automatic HFXO start sequence. The pins used and their purpose are shown in the following tables and differ depending on the STK. To measure wake-up timing from EM2, exit the debugger and return to the IDE. With the STK still connected via the mini USB connector, switch the power selector on the STK to the BAT position and then back to the AEM position to reset the system and observe the different GPIO strobes and their timing.

5.2.1 Normal HFRCO Wake-Up

Set the USE_AUTO_HFXO define in main_cmu_hfxo_autostart.c to 0 to disable the automatic HFXO start feature (USE_LFTIMEOUT is not used here).

In this example, the device will run from the HFRCO when waking up from EM2, and the previously configured HFRCO band (19 MHz in this example) is also restored by hardware on wake-up. The HFRCO has a short wake-up time, and it takes about 10 µs (see the figure below) before the CPU starts running code.

5.2.2 Automatic HFXO Start with Normal Start-Up

Set the USE_LFTIMEOUT define in main_cmu_hfxo_autostart.c to 0 to disable the deterministic HFXO start-up feature (USE_AUTO_HFXO is set to 1).

In this example, the HFXO is automatically started and immediately selected upon waking from EM2 into EM0. The HFSRCCLK is stalled until HFXO becomes ready (see HFSRCCLK output in figure below), which can lead to a relatively long start-up time as the system will run from the HFRCO as it would otherwise do. The normal start-up time varies from crystal to crystal, so the timing of every HFXO start-up (~ 419 µs in this example) differs even with the CMU_HFXOTIMEOUTCTRL register set to the same value.

5.2.3 Automatic HFXO Start with Deterministic Start-Up

Set the USE_LFTIMEOUT define in main_cmu_hfxo_autostart.c to 1 to enable the deterministic HFXO start-up feature (USE_AUTO_HFXO is set to 1).

In this example, HFXO ready assertion is delayed by 16 LFECLK cycles as programmed into the CMU_HFXO_CTRL register LFTIMEOUT bit field to achieve deterministic start-up time (~ 488 µs on every HFXO start-up). The time base typically used for the normal start-up is not as accurate as the time base accuracy that can be achieved for the LFTIMEOUT counter, specifically if the timing is based on the LFXO. For a detailed timing diagram of CMU Automatic startup and selection of HFXO, please refer to the device reference manual.

5.3 Digital Phased-Locked Loop (DPLL)

This software example is run on the EFM32 Pearl Gecko PG12 Starter Kit (project cmu_lfxo_dpll_pg or SLSTK3402A_cmu_lfxo_dpll) with source file main_cmu_lfxo_dpll.c.

The Memory LCD display requires that the pin EXTCOMIN is toggled at a constant frequency to avoid charge buildup. The current Memory LCD display driver uses the RTC/RTCC to trigger a PRS output to toggle the EXTCOMIN pin at the required frequency.

The EFM32 Pearl Gecko PG12 device has a clock output on PRS function, which can achieve this output waveform automatically in EM2 or EM3. The ULFRCO is selected as a PRS producer of CMUCLKOUT0 (PAL_GpioPinAutoToggle() function in main_cmu_lfxo_dpll.c) to toggle the EXTCOMIN pin (PD13), but the pin toggle frequency is fixed at 1 kHz which is much higher than the nominal 64 Hz.

The bool setupDpll(CMU_Osc_TypeDef xtalOsc, uint16_t factorN, uint16_t factorM) function in the main_cmu_lfxo_dpll.c source file is used to set up the DPLL.

Table 5.6. Parameters for setupDpll() Function

This example uses the LFXO as the DPLL reference clock to generate the locked DCO frequency of 24.576 MHz (32768 Hz x 750) from the 26 MHz HFRCO frequency band. Based on the formula in Table 2.20 Digital Phase-Locked Loop Operation on page 23, factor M is 1 for a 32768 Hz Fref if factor N is set to 1499.

The 24.576 MHz HFRCO can be used to generate the bit clock at 3.072 MHz (= 24.576 MHz/8) for a stereo 48 kHz 32-bit I2S data stream. This example configures USART3 as the I2S master to send 48 kHz 32-bit dummy data 0x55AA55AA continuously (see Figure 5.4 USART3 Stereo 48 kHz 32-bit Data I2S Waveform on page 37).

Table 5.7. GPIO Usage on USART3 I2S Master

6. Revision History

6.1 Revision 1.12

March, 2021

• Updated external sine wave minimum voltage in 2.8.1 External Sine Wave

6.2 Revision 1.11

January, 2018

• Removed PLFRCO.
• Removed EFM32JG13 and EFM32PG13 part compatibility.

6.3 Revision 1.10

June, 2017

• Rewrite and addition of EFM32xG13/EFR32xG13 and EFM32 Giant Gecko Series 1.

6.4 Revision 1.00

January, 2017

• Initial revision.