Can I have a GPIO configured as an input and also enable pull-downs or pull-ups on it?
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.
In Precision32 MCUs, there are two classes of interrupt priority: "Preempt Priority" and "Subpriority". Interrupts of like preempt priority cannot interrupt each other, and this is the default state of the peripheral interrupts. Subpriority is used to determine service order when two interrupts of like preempt priority are both pending and the CPU is available to service at their preempt priority level.
See section 4.3 in the SiM3U/C reference manual for more information.
Right click the project name, select [Options]->[C/C++ Compiler]->[Preprocessor]
In [Defined symbols: (one per line)] dialog box, replace the ##bootloader-version-string## with bootloader version number (e.g. BOOTLOADER_VERSION_STRING="2.01")
Due to size constraints, always use the release build to generate the target boot loader binary
Does code compiled in debug mode cause the HFXO to start up more slowly than release mode code?
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.
// 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:
HFRCO Frequency (MHz)
Debug/Release Delta (µs)
Clock Cycles
1
90.4
90
7
18.4
128
11
11.6
128
14
7.2
100
21
6.8
142
28
4
112
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.
Does the frequency of the HFRCO affect the start-up time of the HFXO?
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...
setting the HFXOEN bit in the CMU Oscillator Enable/Disable Command (CMU_OSCENCMD) register,
polling the HFXOENS bit in the CMU Status Register (CMU_STATUS) to verify that the HFXO has been enabled, and
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.
// 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.
1. How accurate is the temperature condition measurement that is placed in the DEVINFO?
During production test, we do not ‘force’ a temperature for room, and it can vary a fair amount. However, in volume production the error should be in the +/-2 degC range.
2. What kind of tolerance is expected on the temperature slope? Will it be linear over -40 deg to 50 deg C?
The slope may actually change a little across the full temperature range. The temp sensor measurement done against an internal reference ultimately sources the internally generated bias voltage. This is not flat across temperature, and there is a slight gradient.
Can I get an accuracy of +/- 0.1 deg C using the internal temp sensors of the 32-bit MCUs?
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.
In some devices that have the flash read-while-write feature (i.e. EFM32GG), it is possible to read from one half of the flash while writing to the other half. The following code example depicts that on a Giant Gecko part:
#include "em_chip.h"
#include "em_device.h"
#include "bsp.h"
/**************************************************************************//**
*
* Programs a single word into flash.
*
*****************************************************************************/
void FLASH_writeWord(uint32_t adr, uint32_t data)
{
/* Enable Read-While-Write feature and write feature */
MSC->WRITECTRL |= MSC_WRITECTRL_RWWEN | MSC_WRITECTRL_WREN;
/* Load address */
MSC->ADDRB = adr;
MSC->WRITECMD = MSC_WRITECMD_LADDRIM;
/* Load data */
MSC->WDATA = data;
/* Trigger write once */
MSC->WRITECMD = MSC_WRITECMD_WRITEONCE;
}
/**************************************************************************//**
* @brief Main function
*****************************************************************************/
int main(void)
{
/* Chip errata */
CHIP_Init();
/* Initialize LED driver */
BSP_LedsInit();
BSP_LedSet(0);
//Write a word to the second half of the main block of flash
FLASH_writeWord (0x00080009, 0x0);
/* Poll till the write is complete */
while (MSC->STATUS & MSC_STATUS_BUSY)
{
// the LED toggling when the flash is being written
BSP_LedToggle(0);
}
/* Infinite loop */
while (1)
;
}
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.
32-bit Knowledge Base
Input Pull-down
Precision32 Interrupt Priority
AN0003 UART Bootloader Start Address for EFM32JG/PG
IAR Build for AN0003 UART Bootloader
Oscillator Startup and Debug vs. Release Mode
HFRCO Frequency and HFXO Start-up Time
Internal Temp Sensors - DEVINFO data and tolerance
Accuracy of internal temperature sensors
Flash read-while-write
Getting the ADC to work with AUX clock