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.
It is possible to configure the CMU to input a clock from the CLKIN0 pin.
This clock can be selected to drive HFSRCCLK and DPLL reference using CMU_HFCLKSEL and CMU_DPLLCTRL respectively.
The required input pin must be enabled in the CMU_ROUTEPEN register and the pin location can be configured in the CMU_ROUTELOC1 register.
The CLKIN0 pin is not available on EFM32xG1 and EFR32xG1 devices.
Code example on EFM32PG12:
// Select HFSRCCLK on CLKOUT1
CMU->CTRL &= ~_CMU_CTRL_CLKOUTSEL1_MASK;
CMU->CTRL |= CMU_CTRL_CLKOUTSEL1_HFSRCCLK;
// Enable CLKOUT1 on PD10 to monitor the HFSRCCLK
CMU_ClockEnable(cmuClock_GPIO, true);
GPIO_PinModeSet(gpioPortD, 10, gpioModePushPull, 0);
CMU->ROUTEPEN |= CMU_ROUTEPEN_CLKOUT1PEN;
CMU->ROUTELOC0 |= CMU_ROUTELOC0_CLKOUT1LOC_LOC4;
// Enable CLKIN0 on PB6
GPIO_PinModeSet(gpioPortB, 6, gpioModeInput, 0);
CMU->ROUTEPEN |= CMU_ROUTEPEN_CLKIN0PEN;
CMU->ROUTELOC1 |= CMU_ROUTELOC1_CLKIN0LOC_LOC3;
// Make sure the related wait state settings are correct and
// CLKIN0 siganl is stable before switching the HFSRCCLK to CLKIN0
CMU->HFCLKSEL = CMU_HFCLKSEL_HF_CLKIN0;
// Update system clock variable in according to CLKIN0 frequency
SystemCoreClock = 8000000;
In data communications, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver. It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node.
The hardware flow control function be introduced into EFM32PG1 / EFM32JG1 / EFM32PG12 / EFM32GG11 USART module. The RTS pin will be controlled by the USART if RTSPEN in USARTn_ROUTEPEN be enabled to allocate the hardware flow control to GPIO, and don’t need any intervention of the firmware. Also the USART will detect the CTS pin to stop the next TX data from going out if CTSPEN and CTSEN be enabled.
RTS is an out going signal which indicates that RX buffer space of USART is available to receive a frame. The link partner is being requested to send its data when RTS is asserted. CTS is an incoming signal to stop the next TX data from going out. When CTS is negated, the frame currently being transmitted is completed before stopping. CTS indicates that the link partner has RX buffer space available, and the local transmitter is clear to send.
All of the serial 0 devices also support hardware flow control and the mechanism be implemented by firmware, please refer to AN0059 example code for how to realize it.
Is there accuracy difference between EFM32/EZR32 series 0 and EFM32/EFR32 series 1 device?
Answer
Yes, the ULFRCO accuracy was greatly improved in EFM32 MCU and EFR32 wrieless SoC series 1 device, comparing with EFM32 MCU and EZR32 wireless MCU series 0 device.
You could get the detailed information in the datasheet of the device.
Silabs added more features on Watchdog module for EFM32 and EFR32 wireless MCU series 1 device, do you have example to guide customer to use these features?
Answer
Comparing with series 0 EFM32/EZR32 MCU, Series 1 EFM32/EFR32 MCU added more advanced features on the watchdog module, the new functionalities include:
Timeout Interrupt without reset.
PRS to clear watchdog.
PRS event monitoring.
Warning interrupt generation.
Window interrupt generation.
You could get the example for demoing these functionality in application note AN0015, you could get the document AN0015 and software AN0015SW.
How to create and link to a static library for EFM32 project with Simplicity Studio?
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:
Is there a way to dump the entire contents of flash on an EFM32 or EFR32 device to a single hex file? I'm using the EFM32 Jade Gecko device, and it has a 256-Kbyte main flash and a 10-Kbyte bootloader partition at two completely separate locations in memory. I would like to combine these into a single file, if possible.
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.
Can I use an 8 GB eMMC in my EFM32 or EFR32 design? I need a large amount of flash storage, but a removable memory card like SDHC is not really a solution for me because it requires a socket.
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.
What analog IO pins are available for user purposes on the Thunderboard React?
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.
What are the voltage requirements when using a sine wave input for the LFXO on EFM32PG1/EFM32JG1 (and EFR32xG1)
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.
32-bit Knowledge Base
HFEXPCLK on MCU Series 1
CLKIN0 on MCU Series 1
Question
What is the usage of CLKIN0?
Answer
It is possible to configure the CMU to input a clock from the CLKIN0 pin.
This clock can be selected to drive HFSRCCLK and DPLL reference using CMU_HFCLKSEL and CMU_DPLLCTRL respectively.
The required input pin must be enabled in the CMU_ROUTEPEN register and the pin location can be configured in the CMU_ROUTELOC1 register.
The CLKIN0 pin is not available on EFM32xG1 and EFR32xG1 devices.
Code example on EFM32PG12:
Note: See "Specifications for External Clock Input via CLKIN0" for more information on CLKIN0
EFM32PG1/EFM32JG1/EFM32PG12/EFM32GG11 USART Hardware flow control introduction.
Accuracy of ULFRCO oscillator for EFM32 MCU and EFR32 SoC series 1 devices
Question
Is there accuracy difference between EFM32/EZR32 series 0 and EFM32/EFR32 series 1 device?
Answer
Yes, the ULFRCO accuracy was greatly improved in EFM32 MCU and EFR32 wrieless SoC series 1 device, comparing with EFM32 MCU and EZR32 wireless MCU series 0 device.
You could get the detailed information in the datasheet of the device.
Take EFM32LG and some series 1 (EFM32PG1B, EFM32PG12B, EFM32GG11B) as example:
Note: there is no characterization data for EFM32GG11B yet.
Related KBA: Series 0 and series 1 EFM32/EZR32/EFR32 device
Watchdog new features on EFM32 and EFR32 wireless MCU series 1 devices
Question
Silabs added more features on Watchdog module for EFM32 and EFR32 wireless MCU series 1 device, do you have example to guide customer to use these features?
Answer
Comparing with series 0 EFM32/EZR32 MCU, Series 1 EFM32/EFR32 MCU added more advanced features on the watchdog module, the new functionalities include:
You could get the example for demoing these functionality in application note AN0015, you could get the document AN0015 and software AN0015SW.
Related KBA: Series 0 and series 1 EFM32/EZR32/EFR32 device
How to create and link to a static library for EFM32 project with Simplicity Studio
Dumping/uploading flash contents on EFM32, EFR32, and EZR32
eMMC and why it is not a suitable microcontroller storage option
Thunderboard React analog IOs
LFXO sine wave voltage requirements