When trying to get a 48 kHz sample rate on EFM32GG with the HFPERCLK set to 48 MHz in I2S mode, I get a clock speed at about 46.9 kHz. Can I get more precision in this clock rate while in master mode?
Answer
The USART clock in master mode is derived by dividing the HPERCLK. The clock divider used in the EFM32 USART is a 15-bit integral part and a 2-bit fractional part. While the hardware supports a fractional divider, it is suppressed while in master mode because it potentially violates specifications for the slave device.
To get the 48 kHz sample rate, the divider register should be configured as 0x700. This is configured in USART_BaudrateSyncSet in the em_usart.c file in emlib.
br = fHFPERCLK/(2*(1+USARTn_CLKDIV/256)
= 48M/(2*(1+0x700/256) = 3MHz
Then
sample per second = br/32/2
= 3M/32/2 = 46.875kHz
If the slave can tolerate some clock duty cycle variation, you could use the fractional part (0x6C0) to get a more accurate clock.
Where can find the USB 2.0 certification report for Wonder Gecko (WG) and Leopard Gecko (LG)?
Answer
You can find a test report for the GG along with the Application Note AN0046 files in Simplicity Studio. To find this document:
Select an EFM32WG or EFM32LG device in the [Enter product name] text box in Solutions pane in Simplicity Studio. Alternatively, connect an EFM32WG or EFM32LG kit, once Simplicity Studio displays the starter kit in Device pane, click on the kit.
Click the [Documentation] tab in right pane, click on [Application Notes], a bench of application note list displayed.
Right click on any application note, a dialog pop up.
Select [AN0046 USB Hardware Design Guide].
Click [Open Folder] at the bottom of the Application Notes dialog.
USB_2.0_Certification_report_Energy_Micro.pdf located at directory doc.
We do not have separate reports for WG and LG, but the software and the USB module are the same.
Where can I find specifications for the internal Gecko MCU VREF?
Answer
We do not have characterization of the internal references by themselves, but the accuracy is reflected in the peripheral characterization. For example, the error numbers of the ADC include the inaccuracies of the internal reference.
The latest EFM32LG datasheet added some characterization data for internal VREF voltage.
When did the SiM3U, SiM3C, and SiM3L devices start containing a device ID?
Answer
All devices after Feb 28, 2013 contain the device ID as specified in the reference manual. Prior to this time, the device ID register contains a unique ID.
When attempting to use I2C on an STK's expansion header pins, I see strange behavior. The I2C lines cannot be pulled to VDD, causing I2C transactions to fail on these pins. What causes this?
Answer
On many EFM32 STKs, some I2C locations share pins with other hardware on the board. For example, the EFM32TG STK has both an LED on PD7 and a phototransistor on PD6, both of which will interfere with I2C traffic if these pins are used for I2C. If these pins must be used for I2C, these two components should be removed from the STK.
How do I determine the location of a section or function in flash or RAM after a project has been linked/built?
Answer
All functions are placed in sections, and the flash and RAM addresses of these sections can be viewed in the .map file.
By default, Studio will generate a .map file in the debug or release folder after a project has been built successfully.
For example, if we build the STK3800_blink project in debug mode, the linker will generate a STK3800_blink.map file in the Debug folder (ie GNU ARM v4.8.3 - Debug).
The map file is organized into several sections:
1. Archive member
2. Allocating common symbols
3. Discarded input section - sections that the linker discarded since they aren't used (ie a function isn't called and variables are unused/optimized away).
4. Memory Configuration - provides a summary of the memory regions configured in the linker script (.ld file).
5. Linker script and memory map - shows a list of object files and library files included in the build and a list of sections showing object/function memory locations and size. For example, here we see that the section .text.Delay is located in flash at 0x00000268 and is 0x2c bytes in length. In this case, the function Delay() is automatically placed in a .text section with the function name appended to the end.
Similarly, variables stored in RAM are normally stored in .data sections.
How do I place a function in a specific memory region using the GCC linker script?
Answer
Placing a function in a specific memory region such as an address range in flash or RAM requires modifications to the linker script and source files to specify a memory region, memory section, and section attribute.
For example, to locate a function, Delay(), in STK3800_blink (EFM32WG), perform the following steps:
1. Create a new MCU project using the EFM32WG STK example, STK3800_blink.
2. Create a custom linker script using the auto-generated debug or release .ld file as a template.
3. Edit the customer linker script as follows:
a. Create a new memory region called MY_REGION, which starts in flash at the 128 KB boundary (0x20000), and is 128 KB in length. The region is specified as readable and executable since flash cannot be written directly. We also reduce the length of the FLASH region to account for this new region.
b. Create a new section called .mysection, which places all objects with a section attribute containing the string .mysection in MY_REGION. We can add this section just after the __etext = .; line so we don't affect the FLASH overflow boundary check. To add overflow checking to make sure that the MY_REGION memory doesn't overflow, we can create pointers to the start and end of the .mysection section by adding __mysection_start__ and __mysection_end__ pointers. The dot (.) symbol indicates the current address during the linking phase.
c. To make sure we don't overflow the MY_MEMORY region, we can add an assert at the end of the linker script to calculate the used length of the MY_MEMORY region and make sure it's less than the total length of the region:
4. Add the __section__ attribute to the function in blink.c, specifying which section the function belongs to:
#define LOCATE_FUNC __attribute__((__section__(".mysection")))
/**************************************************************************//**
* @brief Delays number of msTick Systicks (typically 1 ms)
* @param dlyTicks Number of ticks to delay
*****************************************************************************/
void LOCATE_FUNC Delay(uint32_t dlyTicks)
{
uint32_t curTicks;
curTicks = msTicks;
while ((msTicks - curTicks) < dlyTicks) ;
}
5. Clean and build the project again to use the updated linker script.
6. Open the .map file to verify that the Delay() function is indeed located at 0x20000.
For more information on how to use a custom GCC linker script in Simplicity Studio, see Using a custom linker script in Simplicity IDE.
For more information on how to read the GCC map file to determine the location of a function or section, see Interpreting the GCC map file in Simplicity IDE.
32-bit Knowledge Base
Change the optimization level for a function
Question
How to change a optimization level for a specific function in Simplicity Studio?
Answer
You could use the pragma directive to customize the optimization level for a function like below:
ESD 数据
芯片的质量报告
USART clock speed in EFM32
Question
When trying to get a 48 kHz sample rate on EFM32GG with the HFPERCLK set to 48 MHz in I2S mode, I get a clock speed at about 46.9 kHz. Can I get more precision in this clock rate while in master mode?
Answer
The USART clock in master mode is derived by dividing the HPERCLK. The clock divider used in the EFM32 USART is a 15-bit integral part and a 2-bit fractional part. While the hardware supports a fractional divider, it is suppressed while in master mode because it potentially violates specifications for the slave device.
To get the 48 kHz sample rate, the divider register should be configured as 0x700. This is configured in USART_BaudrateSyncSet in the em_usart.c file in emlib.
br = fHFPERCLK/(2*(1+USARTn_CLKDIV/256)
= 48M/(2*(1+0x700/256) = 3MHz
Then
sample per second = br/32/2
= 3M/32/2 = 46.875kHz
If the slave can tolerate some clock duty cycle variation, you could use the fractional part (0x6C0) to get a more accurate clock.
sample per second = br/32/2
= fHFPERCLK/(2*(1+USARTn_CLKDIV/256)/64
= 48.387kHz
Related KBA: https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2016/07/22/i2s_clock_frequency-L2wr
USB 2.0 certification report for WG and LG series
Question
Where can find the USB 2.0 certification report for Wonder Gecko (WG) and Leopard Gecko (LG)?
Answer
You can find a test report for the GG along with the Application Note AN0046 files in Simplicity Studio. To find this document:
We do not have separate reports for WG and LG, but the software and the USB module are the same.
Gecko MCU VREF Specifications
Device ID in the SiM3 Precision32 Devices
EFM32 STK - difficulties using I2C
Interpreting the GCC map file in Simplicity IDE
Using a linker script in GCC to locate functions at specific memory regions