Answer

We have several application notes and white papers included in Simplicity Studio that addresses this. In particular, please see AN0007, AN0027, and TM0008.

Our website is also a good resource. For example, this page here gives an outline of the power consumption in each mode for each device: http://www.silabs.com/products/mcu/Pages/battery-operation.aspx.

Answer

For ARM Cortex M0+, M3, and M4 devices, such as the EFM32 devices, developers can perform a software reset using the SCB AIRCR SYSRESETREQ bitmask.

See the following ARM documentation for the application interrupt and reset control register:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/Cihehdge.html

Support for this feature is included in CMSIS, and a system reset can be invoked by performing the following steps:

1. Include the appropriate CMSIS header file from the following list: core_cm0plus.h, core_cm3.h, or core_cm4.h.  The appropriate CMSIS core file is automatically included by em_device.h.

Consult the list of 32-bit Families to determine the device architecture type.

2. Call NVIC_SystemReset() to perform a software reset.

Answer

There are two USB audio examples (USB Audio Class 1.0) for the EFM32. These examples can be found using the Software Examples tile in Simplicity Studio.  The two examples are:

usbdheadphone

usbdmicrophone

Both of these examples are available for the EFM32GG, EFM32LG, and EFM32WG Development Kits.

These examples can also be found on disk here by default:

usbdheadphone

C:\SiliconLabs\SimplicityStudio\v3\developer\sdks\efm32\v2\kits\EFM32LG_DK3650\examples\usbdheadphone

C:\SiliconLabs\SimplicityStudio\v3\developer\sdks\efm32\v2\kits\EFM32GG_DK3750\examples\usbdheadphone

C:\SiliconLabs\SimplicityStudio\v3\developer\sdks\efm32\v2\kits\EFM32WG_DK3850\examples\usbdheadphone

usbdmicrophone

C:\SiliconLabs\SimplicityStudio\v3\developer\sdks\efm32\v2\kits\EFM32LG_DK3650\examples\usbdmicrophone

C:\SiliconLabs\SimplicityStudio\v3\developer\sdks\efm32\v2\kits\EFM32GG_DK3750\examples\usbdmicrophone

C:\SiliconLabs\SimplicityStudio\v3\developer\sdks\efm32\v2\kits\EFM32WG_DK3850\examples\usbdmicrophone

If using these USB audio examples for EFM32HG USB devices, it needs to mask off the LEMOSCCTRL bit field in USB_CTRL register. 

  /* Initialize and start USB device stack. */
  USBD_Init(&usbInitStruct);
#ifdef _USB_CTRL_LEMOSCCTRL_MASK
  USB->CTRL &= ~_USB_CTRL_LEMOSCCTRL_MASK;
#endif

Answer

Press setup icon at the right of Energy Profiler.

Select Light on the Theme Selection to change the background color from black to white.

Answer

The frequency range of EFM32JG/PG HFXO is 38 - 40 MHz. The minimum value is much higher than other EFM32s (4 MHz).  

Answer

There is no STK for EFM32JG. Since the only difference between Jade Gecko and Pearl Gecko is the core, the hardware and software development for EFM32JG can be done using an EFM32PG STK.

Any projects developed for EFM32JG should be set to use the ARM Cortex M3 core so the DSP extensions and FPU operations of EFM32PG (ARM Cortex M4) will be disabled by default.

Answer

Unlike other EFM32s, the HFCLKLE cannot be selected as the LETIMER and RTCC clock source for EFM32JG/PG.

The LETIMER and RTCC can be clocked by LFRCO, LFXO or ULFRCO. 

Answer

All GPIO pins within a group of four (0-3,4-7,8-11,12-15) from all ports are grouped together to trigger one interrupt.

So pins within the same group from different ports (e.g. PA0 & PC0) can be selected for the same interrupt source. The example code below demonstrates how to set up PC6 and PF6 as a GPIO interrupt on EFM32JG/PG.

Note:  The Gecko SDK V5.0.0 fixed GPIO_ExtIntConfig() to enable correct interrupt number so this feature does not function properly on previous Gecko SDK.

#include "em_device.h"
#include "em_chip.h"
#include "em_cmu.h"
#include "em_emu.h"
#include "bsp.h"

/**************************************************************************//**
 * @brief GPIO_EVEN_IRQHandler
 * Interrupt Service Routine for even GPIO interrupt
 *****************************************************************************/
void GPIO_EVEN_IRQHandler(void)
{
 uint32_t gpioInt;

 /* Read and clear even GPIO interrupt */
 gpioInt = GPIO->IFC;

 /* Check interrupt from PC6 or PF6 to toggle LED */
 if (gpioInt & 0x0010)
 {
 BSP_LedToggle(0);
 }
 else
 {
 BSP_LedToggle(1);
 }
}

/**************************************************************************//**
 * @brief Main function
 *****************************************************************************/
int main(void)
{
 EMU_DCDCInit_TypeDef dcdcInit = EMU_DCDCINIT_STK_DEFAULT;
 CMU_HFXOInit_TypeDef hfxoInit = CMU_HFXOINIT_STK_DEFAULT;

 /* Chip errata */
 CHIP_Init();

 /* Init DCDC regulator and HFXO with kit specific parameters */
 EMU_DCDCInit(&dcdcInit);
 CMU_HFXOInit(&hfxoInit);

 /* Switch HFCLK to HFXO and disable HFRCO */
 CMU_ClockSelectSet(cmuClock_HF, cmuSelect_HFXO);
 CMU_OscillatorEnable(cmuOsc_HFRCO, false, false);

 /* Enable atomic read-clear operation on reading IFC register */
 MSC->CTRL |= MSC_CTRL_IFCREADCLEAR;

 /* Initialize LED driver */
 BSP_LedsInit();

 /* Setup PC6 & PF6 as input with pullup */
 GPIO_PinModeSet(gpioPortC, 6, gpioModeInputPull, 1);
 GPIO_PinModeSet(gpioPortF, 6, gpioModeInputPull, 1);

 /* PC6 as falling edge trigger on GPIO interrupt source 6 */
 GPIO_ExtIntConfig(gpioPortC, 6, 6, false, true, true);
 /* PF6 as falling edge trigger on GPIO interrupt source 4 */
 GPIO_ExtIntConfig(gpioPortF, 6, 4, false, true, true);

 /* Enable interrupt in core for even GPIO interrupts */
 NVIC_ClearPendingIRQ(GPIO_EVEN_IRQn);
 NVIC_EnableIRQ(GPIO_EVEN_IRQn);

 /* Infinite blink loop */
 while (1)
 {
 EMU_EnterEM3(false);
 }
}

Answer

Bit-banding does work on EFM32; the problem is a lack of specificity in ARM's own documentation. For example, the aforementioned application note (see section 2.5 Bit-banding),  states that "this allows every individual bit in the bit-banding region to be directly accessible from a word-aligned address using a single LDR instruction." However, the example code in that same section uses the 8-bit type unsigned char for the pointer to the bit-band alias region.

The requirement for aligned word accesses to the bit-band alias region is not stated in the Cortex-M3 Devices Generic User Guide or the Cortex-M4 Devices Generic User Guide. In fact, these documents state quite the opposite that "bit-band accesses can use byte, halfword, or word transfers. The bit band transfer size matches the transfer size of the instruction making the bit band access." Similar statements can be found in the reference manuals for ARM's version 4- and 5-series C compilers.

So, which statements and documentation about bit-band transfer sizes and access alignment are true?

It turns out that the latter statements regarding bit-banding are the correct ones. In simple terms, whatever access size is presented to the bit-bander is the same access size that accompanies the resulting bus cycle(s) for reads or atomic read-modify-writes.

This actually makes sense when you think about it. Every ARM MCU vendor has their own implementations of peripherals like timers, serial ports, etc. Each vendor can choose what size accesses a particular peripheral might support. For example, it's not uncommon for a simple timer to have only a 16-bit counter and 16-bit registers. GPIO ports are often organized into 8-port ports with associated 8-bit registers.

So, in this respect, the bit-bander is designed to work with whatever peripherals might be mapped into the bit-banded peripheral address space, regardless of whatever access sizes might be supported.

ARM's example code cited above assumes as much. Why, then, can the peripheral bit-band macro issue 8-bit writes to bits [7:0] of a peripheral register in the bit-band region but not otherwise write bits [31:8]? The answer is simple:

On the Gecko devices, the peripheral registers are 32 bits wide, and writes, specifically, must also be 32 bits in size.

For example, if you use this loop to set each bit in GPIO_PD_DOUT one at a time with bit-banded accesses...

for (i = 0; i < 16; i++) *((volatile uint32_t *)(0x42000000 + 0x6078 * 0x20 + i * 4)) = (uint32_t)0x1;

...it works as expected because the writes to the bit-band space are 32-bit, and the resulting atomic read-modify-write cycles are also 32-bit. However, if you try to clear each bit, one after another, in reverse order using this loop...

for (i = 15; i >= 0; i--) *((volatile unsigned char *)(0x42000000 + 0x6078 * 0x20 + i * 4)) = (unsigned char)0x0;

...it doesn't work. Bits [15:8] remain unchanged, but when the code gets to bit 7, it and each subsequent bit is cleared as expected. This all comes back to the peripheral registers on Gecko requiring 32-bit writes. Anything else will not behave as expected.

If you would like to use bit-banding in your application, there are two options for making sure it to works:

1. Use em_bitband.h and the bit-banding macros it provides. You'll get the benefit of properly constructed bit-band addresses, and you don't have to use the higher-level functions of emlib if you don't want/need them.
2. Make sure whatever bit-band macros you construct use a 32-bit type for all integers, e.g. int, unsigned int, uint32_t, etc.

Please note that none of this applies to EFM32 devices that use the Cortex-M0+ like Zero Gecko or Happy Gecko. Bit-banding is not a feature of the M0+ core as delivered by ARM, and neither Zero nor Happy Gecko incorporates any logic to implement it.