Answer

Yes. For example, it is possible to have a GPIO configured to be an input to ACOMP0 while also enabling its pulldown filter. This can prevent false triggers if the pin is ever left floating.

Answer

The EFM32JG/PG pre-programmed bootloader is located in 0x0FE10000 and this bootloader flash area is readable by software but not writable.

To customize the bootloader, change the start address in config.h header file from 0x0FE10000 to 0x0 as shown below.

Original settings:

#elif defined(_SILICON_LABS_32B_PLATFORM_2)
#define BOOTLOADER_SIZE         (10*1024)
#define BOOTLOADER_START_ADDR   (0x0FE10000)
#define APPLICATION_START_ADDR  (0)

Customized settings (e.g. bootloader size is 4 KB):

#elif defined(_SILICON_LABS_32B_PLATFORM_2)
#define BOOTLOADER_SIZE         (4*1024)
#define BOOTLOADER_START_ADDR   (0)
#define APPLICATION_START_ADDR  BOOTLOADER_SIZE

Answer

The procedure to build the AN0003 IAR project is:

1. Right click the project name, select [Options]->[C/C++ Compiler]->[Preprocessor]
2. In [Defined symbols: (one per line)] dialog box, replace the ##bootloader-version-string## with bootloader version number (e.g. BOOTLOADER_VERSION_STRING="2.01")
3. Due to size constraints, always use the release build to generate the target boot loader binary

 Original setting:

Build setting:

Answer

As discussed in the knowledge base article HFRCO Frequency and HFXO Start-up Time, there is software overhead involved in starting the HFXO when using the emlib CMU_OscillatorEnable() function. Naturally, if the high frequency clock (HFCLK) runs faster, so does this code.

It follows, then, that there may be some impact on HFXO start-up if your code is compiled in debug mode instead of release mode. Debug code is compiled without optimization and includes error checking assertions and various instruction sequencing constructs to preserve traceability and local variable visibility. This can slow some tasks substantially, such as toggling a GPIO pin, which runs about 7 times slow in debug mode than release mode.

Consider the following simple program, tested on the Giant Gecko STK3700 Starter Kit, which selects the HFRCO 1 MHz band and toggles GPIO pin D0 high then low after calling the emlib CMU_OscillatorEnable() function to start the HFXO and wait for it to stabilize.

#include "em_device.h"
#include "em_chip.h"
#include "em_cmu.h"
#include "em_gpio.h"

int main(void)
{
  CHIP_Init();

  // Switch to desired HFRCO band
  CMU_HFRCOBandSet(cmuHFRCOBand_1MHz);

  // Enable GPIO clock and configure PD0 as output
  CMU_ClockEnable(cmuClock_GPIO, true);
  GPIO_PinModeSet(gpioPortD, 0, gpioModePushPull, 0);

  // Drive PD0 high to denote start of HFXO switchover
  GPIO_PinOutSet(gpioPortD, 0);

  // Switch to HFXO and wait for stabilization
  CMU_OscillatorEnable(cmuOsc_HFXO, true, true);

  // Drive PD0 low to denote switchover completion
  GPIO_PinOutClear(gpioPortD, 0);

  // Pause code here when done
  __BKPT(0);
}

If you dig into the source code for CMU_OscillatorEnable(), you will see that it follows the HFXO start-up procedure (actually the proper start-up procedure for user-controllable oscillators on all EFM32 devices) outlined above. Here are the pulses output by this program for each of the HFRCO frequency bands (1, 7, 11, 14, 21, and 28 MHz) when compiled in debug mode vs. release mode:

At 1 MHz, the difference is a sizable 90 µs, which could account for as many as 90 single-cycle Cortex-M3 instructions. Interestingly, the number of clock cycles delay between debug and release modes is not constant as shown in the following table:

Because the HFXO is starting the same crystal on the STK each time, the physical mechanics of this should be the same. Furthermore, as cited in the article above, the bulk of the delay incurred by CMU_OscillatorEnable() comes from the default 16,384 HFXO cycles selected by the HFXOTIMEOUT field in CMU_CTRL.

So, what accounts for the non-deterministic number of clock cycles difference between release and debug mode? It's safe to assume that the jump that occurs between 14 and 21 MHz is partly due to the extra wait state needed for flash accesses at frequencies above 16 MHz. Otherwise, the difference probably relates to the fact that the HFXO timeout counter circuit operates in a different clock domain from the actual CMU registers. Because these domains are asynchronous (e.g. the timeout circuit is clocked at 48 MHz when running from the crystal on the STK but HFCLK is driven by the HFRCO), there will always be some indeterminate delay from when the HFXO timeout delay count has been reached to when the HFXORDY flag is set in the CMU_STATUS register.

Answer

No, it does not.

The HFXO (High Frequency Crystal Oscillator) is, in the simplest sense, just an inverting amplifier. Powering it up causes a connected crystal to oscillate, subject to certain tuning parameters. While the HFRCO provides the high frequency clock (HFCLK) for EFM32 microcontrollers out of reset, it plays no role in the functionality of the HFXO.

So, why might the HFRCO seem to impact HFXO start-up time?

Enabling the HFXO is usually not a set-and-forget procedure. While it may be allowable to set the HFXOEN bit in the CMU_OSCENCMD register and continue on with other initialization tasks such that the HFXO will have stabilized by the time the main application code is ready to run, in most cases, verifying oscillator start-up is a requirement for proper system functionality and reliability.

Given this, the correct HFXO start-up procedure entails...

1. setting the HFXOEN bit in the CMU Oscillator Enable/Disable Command (CMU_OSCENCMD) register,
2. polling the HFXOENS bit in the CMU Status Register (CMU_STATUS) to verify that the HFXO has been enabled, and
3. polling the HFXORDY bit (also in CMU_STATUS) to verify that the oscillator start-up time has elapsed.

Note that the HFXORDY bit is set in response to the number of HFXO cycles specified by the CMU Control Register (CMU_CTRL) HFXOTIMEOUT field elapsing. This defaults to 0x3, equating to a time out period of 16384 cycles. As you can see, this is the gating factor in the HFXO start-up delay, and it can be reduced when a clock source that more quickly ramps up to its rated frequency is used.

Because the HFXO start-up sequence consists of setting and polling various bits, it should follow that the time this takes to run is directly proportional to the HFCLK frequency, which, at boot, is provided by the HFRCO.

Consider the following simple program, tested on the Giant Gecko STK3700 Starter Kit, which selects the HFRCO 1 MHz band and toggles GPIO pin D0 high then low after calling the emlib CMU_OscillatorEnable() function to start the HFXO and wait for it to stabilize.

#include "em_device.h"
#include "em_chip.h"
#include "em_cmu.h"
#include "em_gpio.h"

int main(void)
{
    CHIP_Init();

  // Switch to desired HFRCO band
    CMU_HFRCOBandSet(cmuHFRCOBand_1MHz);

  // Enable GPIO clock and configure PD0 as output
  CMU_ClockEnable(cmuClock_GPIO, true);
  GPIO_PinModeSet(gpioPortD, 0, gpioModePushPull, 0);

  // Drive PD0 high to denote start of HFXO switchover
  GPIO_PinOutSet(gpioPortD, 0);

  // Switch to HFXO and wait for stabilization
  CMU_OscillatorEnable(cmuOsc_HFXO, true, true);

  // Drive PD0 low to denote switchover completion
  GPIO_PinOutClear(gpioPortD, 0);

  // Pause code here when done
  __BKPT(0);
}

If you dig into the source code for CMU_OscillatorEnable(), you will see that it follows the HFXO start-up procedure (actually the proper start-up procedure for user-controllable oscillators on all EFM32 devices) outlined above. Here are the pulses output by this program for each of the HFRCO frequency bands (1, 7, 11, 14, 21, and 28 MHz).

Each step to the next higher HFRCO frequency band brings with it a reduction in the time required for CMU_OscillatorEnable() to execute. The biggest drop comes when going from 1 MHz up to 7 MHz, with subsequent decreases being roughly proportional to the reduction in the HFCLK cycle time due to the increased HFRCO frequency.

Regardless of the HFRCO frequency, the bulk of the wait comes from the default 16,384 HFXO cycles selected by the HFXOTIMEOUT field in CMU_CTRL. For the 48 MHz crystal on the Giant Gecko STK, this would amount to 341.3 µs if it were already running.

What remains is about 50 µs of relatively fixed delay courtesy of crystal start-up effects and logic in the HFXO enabling circuit. Goosing the HFCLK frequency by means of the TUNING field in the HFRCO Control Register (CMU_HFRCOCTRL) bears this out. At 35 MHz (about the tunable maximum), the pulse generated in the demo program shrinks just 0.4 µs despite the 25% increase in clock frequency over 28 MHz.

Please note that the HFXO has two dedicated control registers on Jade and Pearl Gecko and the EFR32 family. These devices follow a somewhat different procedure that involves CMU_OscillatorEnable() performing certain optimizations only when the HFXO is started for the first time and not upon subsequent restarts. Consequently, the start-up delay can differ substantially from that on Giant Gecko and related devices.

Answer

No. This is primarily because the temp sensor is going to have a large variation in both offset and slope. We do calibrate out offset error at a known temperature, but the slope error will easily contribute +/-3 degrees or more over the full temperature range of our parts. It would be possible to do a part-by-part two-point calibration in system to get higher accuracy. There are many sources of error besides just the sensor itself – the ADC, reference, and even how much self-heating the chip is experiencing at the time are all going to contribute.

If 0.1 degrees C is an absolute requirement, then the Si7051 device would be a better choice, since it is a stand-alone temperature sensor that provides that level of accuracy over the entire operating range of temperature and voltage. 

Answer

To set AUXHFRCO as the clock for the ADC, certain register configurations must be made which are not included in emlib functions. The figure below is a part of the CMU Overview - High Frequency portion taken from the reference manual of Pearl Gecko:

As it can be seen in this figure, to select the AUXHFRCO as the ADC Clock, the CMU_ADCCTRL.ADCCLKSEL bit needs to be set accordingly. Once this change is made, the ADC_CLKMODE register also needs to be changed. 

While enabling a clock, the following change needs to be made:

// Select the AUXHFRCO as the ADC clock 
CMU->ADCCTRL = CMU_ADCCTRL_ADC0CLKSEL_AUXHFRCO; 

In the ADC Setup:

// Make this change to ensure the AUXHFRCO is selected 
ADC0->CTRL = ADC_CTRL_ADCCLKMODE_ASYNC;

The other settings of the ADC remain unchanged and can be referred to from the AppNote AN0021.  Application Notes can be found within Simplicity Studio (www.silabs.com/simplicity) or on the website at www.silabs.com/32bit-appnotes.