Answer

The HFEXPCLK is a prescaled version of HFCLK as controlled by the PRESC bitfield in the CMU_HFEXPPRESC register.
HFCLK will not have a 50-50 duty cycle when any other division factor than 1 is used in CMU_HFPRESC (i.e. if PRESC is not equal to 0).

In such a case, the exported HFEXPCLK will therefore also not be 50-50 when its division factor is not set to an even number in CMU_HFEXPPRESC.

Code example on EFM32PG12:

  // Select 32 MHz HFRCO as HFCLK  
  CMU_HFRCOBandSet(cmuHFRCOFreq_32M0Hz);

  // Divide HFCLK by 4 (8 MHz) on HFEXPCLK
  CMU->HFEXPPRESC &= ~_CMU_HFEXPPRESC_PRESC_MASK;
  CMU->HFEXPPRESC |= (3 << _CMU_HFEXPPRESC_PRESC_SHIFT);

  // Select HFEXPCLK on CLKOUT1
  CMU->CTRL &= ~_CMU_CTRL_CLKOUTSEL1_MASK;
  CMU->CTRL |= CMU_CTRL_CLKOUTSEL1_HFEXPCLK;
  
  // Enable CLKOUT1 on PD10
  CMU_ClockEnable(cmuClock_GPIO, true);
  GPIO_PinModeSet(gpioPortD, 10, gpioModePushPull, 0);
  CMU->ROUTEPEN |= CMU_ROUTEPEN_CLKOUT1PEN;
  CMU->ROUTELOC0 |= CMU_ROUTELOC0_CLKOUT1LOC_LOC4;

Answer

Static libraries contain code that is linked at compile time to the project calling it.  It can be used to provide reusable functions or to distribute code in a binary-only format (a header file will still be needed). Below example take the EFM32PG1 STK with GNU ARM toolchain as example.

To create a static library, go to File -> New -> Project... -> Silicon Labs MCU Project and select Library, You could rename the project name, here let me assume we use the default name "staticLibrary":

Write any functions you want the library to contain.  Library functions can call other library functions.  Be sure to create a header file containing prototypes for the functions you wish to be called from the linking project.  There will be no main() function in the library.  Build this project and you would get the library file with name "libstaticLibrary.a".

Create a new project to link to the library (or use an existing project).

Add the library's .lib file to the linker by going to Properties -> C/C++ Build -> Settings -> Tool Settings -> GNU ARM Linker -> Libraries -> Libraries (-l) -> Add.  Add the library file "libstaticLibrary.a" to the project. Be sure to drop the "lib" prefix and 'a' extension file name.

Add directory that include the library "libstaticLibray.a" into the Library search path by going to Properties -> C/C++ Build -> Settings -> Tool Settings -> GNU ARM Linker -> Libraries -> Library search path(-L) -> Add.

Add the header file for the libraries to the project.  Properties -> C/C++ Build -> Settings -> Tool Settings -> GNU ARM C Compiler -> Includes -> Add... path.

You can now call functions from the library. build the project and debug it on the EFM32PG1 STK:

Answer

Simplicity Commander (or just Commander, for short) is a tool for EFM32, EFR32, and EZR32 families that can be used to program the on-chip flash, unlock debug access, and update the firmware on Starter Kits for these devices. It is cross-platform (Windows, Macintosh, and Linux) and has both GUI and command line interfaces. One of the things it can do from the command line is upload the contents of flash on a connected device.

Flash upload is performed using the readmem command and appropriate options to specify the memory range to upload and the output file. It's easy to find out about the options available for readmem by adding the --help flag when invoked from the command line, like so:

There are two ways to tell Commander what to upload from flash. One is simply to specify the address range desired with the --range flag and appropriate start and end addresses:

It's also possible to upload flash using names for the different regions with the --region flag, but this requires knowing the regions that can be uploaded. Fortunately, it's simple to find out what named regions are available by invoking Commander with readmem and --region followed by the --help flag:

So, uploading the complete contents of the main flash array on a Pearl Gecko 12 (or really any EFM32/EFR32/EZR32) device can be done with:

Finally, getting to the question at hand, dumping the entire contents of flash is simply a matter of adding a --region flag for each named region on the command line. The Device Information (DI) page, which is the @devinfo named region, is skipped in this case since it is write-protected and not intended to be reprogrammed by the user:

Verifying that all of these regions were written to the designated output file would be painful if it were necessary to manually interpret the hex file by loading it into a text editor. Instead, the attached hexinfo utility for Windows (built from the cross-platform source found here) parses a given hex file and outputs the byte count of data in each referenced address range. As shown below, the allflash.hex file created in the previous step includes the 1 MB main, 2 KB user data, 2 KB lock bits, and 38 KB bootloader regions of flash on the Pearl Gecko 12 device.

Answer

Unfortunately, even though eMMC is a managed NAND solution (see the Knowledge Base article "Is there a way to add multiple gigabytes of storage to my EFR32 design?" for a discussion of managed NAND solutions), it is not an option for embedded devices like Blue Gecko.

Here's the story behind why this is the case:

Samsung developed one of several removable memory card standards in the early days of digital imaging called MultiMedia Card or MMC. In order to allow it to be used with embedded devices that did not have a dedicated hardware controller interface, Samsung added a SPI transfer mode that could be used in place of MMC's single clock, command, and data lines.

With digital imaging no longer a novelty, consumers began to pick winners and losers among the various memory card formats. As one of the early entrants in the market, SmartMedia (known formally as SSFDC for Solid State Floppy Disk Card), began to lose acceptance, its primary technology backer, Toshiba, got together with SanDisk and Panasonic to create the Secure Digital (SD) card standard. They essentially took the MMC standard, expanded the data bus to 4 bits, and added security features (essentially DRM for digital music) that were never really embraced by consumer electronics companies. Samsung responded by changing the name of the MMC standard to MMCplus, expanding the data bus to 4 or 8 bits, and increasing the clock frequency.

Looking back, the argument could be made that MMCplus was the superior memory card standard because it supported things not available in SD (at least at the time) like operation down to 1.8V. Additionally, when the need for physically smaller cards arose, MMCplus introduced the Reduced Size MMC (RS-MMC), an elegant form factor that essentially cut the vertical dimension of the card in half and added a physical extension as an adapter...

...as opposed to the kludgy MiniSD and its slide in adapter:

Of course, these mini versions didn't last very long, and both standards went to an entirely different, physically smaller format, with the SD Association taking ownership of SanDisk's TransFlash and making it their micro format:

As went the digital imaging market (and, by extension, mobile phones), so went memory cards. MMCplus never got the traction of SD, and Samsung ultimately turned the standard over to JEDEC. However, the story doesn't end here.

Samsung and other vendors, like SanDisk, had started working on what were essentially chip scale versions of their memory cards. These devices would come in packages with solder balls and were intended to be permanently attached to printed circuit boards.

Naturally, Samsung called theirs eMMC, for embedded MMC, and JEDEC, arguably, assumed ownership of the MMCplus standard really for the purpose of advancing eMMC and not the card formats. So, while SD dominated the memory card market, eMMC quietly began building a head of steam and ultimately became the de facto choice for high capacity on-board storage, driven by, surprise, surprise, the increasing difficulty of using raw NAND components and the impact it had on both SoC designs and operating system software (meaning the Linux kernel).

Mobile phone manufacturers, almost without exception, use eMMC for their on-board storage. The same applies to things like streaming TV boxes, car navigation and infotainment systems, and even super, low-cost notebooks and convertibles running Windows or Chrome OS (if they have 16 or 32 GB of storage, they use eMMC). Even SanDisk, whose iNAND embedded storage devices were at first SD cards in a chip package, ultimately moved to eMMC.

What, ultimately, does this have to do with using eMMC with EFM32, EFR32, and EZR32? Somewhere along the way as the eMMC standard evolved, maybe even in its first iteration, the least common denominator SPI transfer mode that was always supported by MMC was dropped. Without dedicated controller hardware (eMMC supports the original MMC 1-bit data bus in addition to the MMCplus 4- and 8-bit wide options), it's rather painful to interface an eMMC. Bit-banging is certainly possible if the dismal transfer rates can be tolerated because DMA is not an option as is the case when SPI is used with an SD card.

Answer

Pins PD13, PD14, PD15, and PA5 are available as analog inputs, and routed to user accessible pads.  See the schematic (available in Simplicity Studio) for more information.

Answer

For a sine wave input the amplitude must be a minimum of 200mV peak to peak, and a maximum of 1V peak to peak.  There is no requirement on offsets, other than the peaks must stay within the supply range.