32-bit Knowledge Base

    Publish
     
      • Difference in capsense between AN0028 and ZG/HG demos

        jstine | 12/345/2017 | 11:53 AM
        Capsense projects using LESENSE, as described in AN0028 are able to manage the comparators through LESENSE in EM2, reducing the amount of power needed to run the example.  Parts like the EFM32ZG, EFM32HG and EFM32PG1 do not have LESENSE.  They can implement a capacitive sensor using the comparators, however the part must be in EM1 or EM0, increasing the amount of power used.
      • Using GPIO pull up and pull down on analog signals

        jstine | 12/345/2017 | 11:36 AM

        Is it possible to use digital GPIO pull up and pull down functionality on a pin that is connected to APORT on EFM32PG1?


        Yes, the pull up and pull down functionality of the GPIO block can be used.  This will enable the input buffer and may cause increased current consumption if both transistors of the input buffer are activated by an intermediate signal.  This will also enable over voltage tolerance circuitry which may cause a slight distortion (only noticeable at 12 bits of precision) and a slight increase in settling time. 

      • Immediate and delayed synchronization on Low Energy Peripheral of EFM32 and EFR32

        amenleung | 12/341/2017 | 01:06 AM

        Writing

        Every Low Energy Peripheral has one or more registers with data that needs to be synchronized into the Low Energy clock domain to maintain data consistency and predictable operation. There are two different synchronization mechanisms on the EFM32 and EFR32 devices, immediate synchronization, and delayed synchronization.

        Immediate synchronization is available for the RTCC, LESENSE, RTC and LETIMER, and results in an immediate update of the target registers. Delayed synchronization is used for the remaining Low Energy Peripherals (LEUART, LCD, PCNT, and WDOG), and for these peripherals, a write operation requires 3 positive edges of the prescaled clock on the Low Energy Peripheral being accessed.

        Registers requiring synchronization are marked "Async Reg" in their description header, even for perpherals' registers that support immediate synchronization.

        Note: On the EFM32G devices, all LE peripherals are subject to delayed synchronization.

        After writing data to a register which value is to be synchronized into the Low Energy Peripheral using delayed synchronization, a corresponding busy flag in the _SYNCBUSY register (e.g. LETIMER_SYNCBUSY) is set. This flag is set as long as synchronization is in progress and is cleared upon completion. 

        Reading

        When reading from a Low Energy Peripheral, the data read is synchronized regardless if it originates in the Low Energy clock domain or High Frequency clock domain.

      • Creating a Stackless EFR32 Project

        Stephen | 12/340/2017 | 01:03 PM

        Question

        I am using an EFR32 device and will not be using the radio. I do want to use other peripherals such as USART, I2C, ADC, etc. I do not want a project with the radio stack.

        Furthermore, I do not want to start with the SoC Empty project (from the Bluetooth SDK), or a Z3* project (from the EmberZNet SDK), or a Connect* project (from the Flex SDK), i.e. I do not want to use Appbuilder (starting with a .isc file) to generate a project.

        How do I create an empty, stackless project for EFR32?

         

        Answer

        1. In the Simplicity Studio IDE menu bar, click on [Project]>[New Silicon Labs Project]
        2. Type in part number, Select [Gecko SDK Suite] for [SDK]>[Next]
        3. Select [Empty C Project]>[Next]
        4. Finish
        5. Now back in the IDE, in the Project Explorer
          • Copy-paste the emlib source files (em_core.c, em_cmu.c, em_gpio.c, em_usart.c) for every peripheral you plan on using into the emlib folder. The emlib source files can be found on your hard drive:  C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.1\platform\emlib\src
        6. Begin adding your code to the auto-generated main.c file.

        Note: You must specifiy the "include path" to every header file used by your project in the project settings. Using the procedure above, include paths for the EFR32 header files and the emlib header files are automatically specified in the project settings. Additional include paths can be added by:

        1. In the IDE, in the Project Explorer, right click the [project name]>[Properties]
        2. Navigate to C/C++ Build Settings
        • If you are using GCC: continue navigating to [GNU ARM C Compiler]>[Includes]
        • If you are using IAR: continue navigating to [IAR C/C++ Compiler for ARM]>[Preprocessor]

         

      • Software Documentation

        Alan_S | 12/339/2017 | 06:44 PM

        Looking for documentation that explains our HAL or driver API's?

        We have a doxygen website that hosts a multitude of useful information about how software such as how to use emlib. This is a great resource for people new to our tools or who want more information on specific functions in our libraries - 

        http://devtools.silabs.com/dl/documentation/doxygen/

      • Why doesn't debug unlock erase the bootloader on EFM32 Series 1 devices?

        JohnB | 12/335/2017 | 04:18 PM

        Our bootloader contains decryption and authentication keys (AES-128 / CMAC / OMAC1) for the software image. The bootloader will only process software images that can be authenticated and decrypted correctly. I noticed that it is possible to dump the bootloader memory with J-Link, even after performing a debug unlock operation, which is supposed to perform a full chip erase. This is a problem for us because the keys should not be able to be read out of the chip. Is this something that is going to be fixed in a future chip revision, or is it "as-designed"?
         

        While this may come as a suprise to some, the MCU is operating as-designed. Debug unlock does not erase the bootloader region of flash.

        Dear readers, you might look at this and immediately think, "Wait a second? How can you call it a full-chip erase if the bootloader region remains intact after a debug unlock operation? This doesn't seem very secure!"

        Semantics aside, in this particular case, the customer is not using the bootloader space correctly.

        The reason for not erasing the bootloader is simple. During development, you might be testing code that locks the debug interface because it's a critical part of your product security. If software worked as expected 100% of the time, there wouldn't be a need for flash memory, so you can see that there has to be a way to initiate a debug unlock sequence (e.g. via Simplicity Commander) to recover the device. Silicon Labs leaves the bootloader intact after this operation so that you can re-image the device with updated code.

        "But what about the encryption keys or anything else that might be stored in the bootloader space that is critical to product security? If those aren't erased, it would be a simple matter for some ne'er-do-well to use this to create a fake firmware image that allows my valuable software to be stolen," you say.

        While true, the problem here is that you should not be storing hashes or encryption keys in the bootloader space in the first place. As the description of Debug Lock in the Debug Interface chapter of the reference manual explains, "this operation erases the main block of flash, clears all lock bits, and debug access to the Cortex-M4 and bus-system is enabled." Any information that you consider sensitive — firmware, encryption keys, binary image hashes, etc. — must be stored in the main block of flash in order to guarantee that it is erased and thus kept confidential.

        If there is a further concern that, even with proper isolation of encyrption keys and related hashes in main flash block, product security can still be compromised with visibility of the bootloader after debug unlock, consideration should be given to partitioning the bootloader into generic and sensitive components.

        Things like serial communications drivers or flash erase/write routines, generic code for which visibility wouldn't provide a hacker with information that could compromise product security, can be stored in the bootloader space. Sensitive components, say, perhaps, a handler for the firmware update protocol or specific crytographic algorithms, could be stored in the main flash array where they would be securely erased as part of the debug unlock process.

      • Current Consumption Example?

        Alan_S | 11/331/2017 | 06:27 PM

        I am trying to reproduce the current consumption numbers specified in the datasheet of an EFM32 device. How do I make sure that I am using the same settings as the numbers in the datasheet?

        Provided with Simplicity Studio is a set of software examples that demonstrate how to use the device's various peripherals. One of these examples is PowerModes and shows how to put the device into its various low power states. In Simplicity Studio, this code is listed under Software Examples when you have your device selected.

      • Introduce the LCD power reduction feature on EFM32 series 1 devices

        yucheng | 11/327/2017 | 02:25 AM

        Segmented LCD displays are common way to display information. The extreme low-power LCD driver enables a lot of applications to utilize an LCD display even in energy critical systems.

        A new power reduction feature Charge Redistribution be introduced in the series 1 devices (e.g. EFM32GG11). The power consumption of the LCD panel itself can be lowered through the use of charge redistribution. When charge redistribution is in use, all segments are briefly shorted together, allowing low segments to be partially charged by the energy in high segments instead of using additional energy from the power supply. For our test, it can reduce up to around 40% power consumption in NORMAL wave mode, and 10% to 24% power consumption when LCD module in Low Power wave mode.

        Before introducing how to set the charge redistribution more effectively, the section below will show how to choose the frame rate firstly.

        Normally, the frame rate should be between 30 and 100 Hz. A frame rate below 30 Hz may lead to flickering, while a frame rate above 100 Hz may lead to ghost ring and unnecessarily high power consumption.

        The frame rate phase frequency is set with FR Divider (FRDIV) in LCD_FRAMERATE register, the equation for calculating the resulting frame rate phase frequency is given below.

        The LFACLK is prescaled to LFACLKLCDpre in the CMU (be controlled by the bit fields of LCD in CMU_LFAPRESC0 register), and the LFACLK can be selected from LFXO, LFRCO or ULFRCO in the CMU.

         

        For setting the charge redistribution, CHGRDST in LCD_DISPCTRL is used to select the number of prescaled LFCLKLCD cycles used for charge redistribution. The formula below show how to calculate the charge redistribution cycle percentage (CHGRDST PERCENT).

        It can reduce more power consumption with higher cycle percentage, however, the RMS voltage will be reduced in LCD pad. The charge redistribution cycle percentage should be 5% or less to prevent reduction in LCD pad RMS voltage.

        The CHGRDST PERCENT be decided by CHGRDST and FR Divider simultaneously, the CHGRDST can be set as 0 to 4, and the FR Divider should no less than 20 times of the CHGRDST to make sure that the cycle percentage no more than 5%.

        For example, if select the LFRCO (32768 Hz) as the LE interface clock, and set the CHGRDST as 3, the FRDIV should no less than 60. For getting a reasonable frame rate (between 30 and 100) when octaplex multiplexing be selected, the prescaler should be set to 1, and set FRDIV as 63 to get the 32 Hz frame rate.

        The finial frame rate be calculated by the equation below.

        Frame rate=LFRCO/(Prescaler*(63+1)*16)=32 Hz

        Generally speaking, a smaller CMU prescaling value and a big FRDIV value is suggested to work out a reasonable charge redistribution cycle percentage.
        If the charge redistribution is not used, a larger CMU prescaling value is recommended to minimize power consumed by the LCD block itself. Note that disabling charge redistribution will always result in higher system power consumption. Charge redistribution is on by default, but it can be disabled by setting CHGRDST to disable in LCD_DISPCTRL.
         

      • Determining LCD compatibility with EFM32GG11

        marao | 11/320/2017 | 05:38 PM

        While considering the compatibility of LCD with EFM32GG11, one must consider factors like resolution, bits per pixel, and refresh rate while determining a good fit. Here is an example that explains more - 

        Consider a color LCD of 800x400 pixels resolution with 24-bits per pixel. Let us assume a refresh rate of 60 Hz. The Giant Gecko 11 will be unable to support a LCD of the resolution above because of the following reasons - 

        Data transfer rate = resolution x refresh rate x bits per pixel / 8 bits per byte

        Data transfer rate = 800 x 400 x 60 x 24 / 8 = 55 Mega Bytes per second

        The GPIOs of the EFM32GG11 cannot toggle at that fast rate in order to transmit the required data. Even with the TFT controlling the GPIOs, it will not be able to handle speeds as high as what is shown above.

        Additionally, Table 4.35 in the Giant Gecko 11 datasheet shows the formula for the minimum pulse width of the EBI_WE (Fig 4.3)

        Using the formula for IOVDD >= 3.0 V and setting WRSTRB to its highest value (i.e., 1) for maximum pulse width, we see that

        EBI_WEn pulse width = -4.04+((WRSTRB+1)*tHFCORECLK)

        EBI_WEn pulse width  = -4.04+2x 13.9* ns

        EBI_WEn pulse width = 23.74 ns

        *the 13.9 ns is an inverse of 1/72 MHz expressed in nano seconds

        Now, if this is inverted, we get a bus speed of 42 MBytes per second which is still less than the desired data speed and also theoretical since it does not account for the practical limitations of the TFT controller. 

        There is no one answer for the maximum resolution that the device can support since it is dependent on several factors. But the GG11 can support a QVGA with 60 Hz refresh rate. That can be used as a base to then determine compatibility with other LCDs.  

      • Why doesn't debug unlock erase the bootloader on EFR32 devices?

        JohnB | 11/317/2017 | 07:07 PM

        Our bootloader contains decryption and authentication keys (AES-128 / CMAC / OMAC1) for the software image. The bootloader will only process software images that can be authenticated and decrypted correctly. I noticed that it is possible to dump the bootloader memory with J-Link, even after performing a debug unlock operation, which is supposed to perform a full chip erase. This is a problem for us because the keys should not be able to be read out of the chip. Is this something that is going to be fixed in a future chip revision, or is it "as-designed"?
         

        While this may come as a suprise to some, the MCU is operating as-designed. Debug unlock does not erase the bootloader region of flash.

        Dear readers, you might look at this and immediately think, "Wait a second? How can you call it a full-chip erase if the bootloader region remains intact after a debug unlock operation? This doesn't seem very secure!"

        Semantics aside, in this particular case, the customer is not using the bootloader space correctly.

        The reason for not erasing the bootloader is simple. During development, you might be testing code that locks the debug interface because it's a critical part of your product security. If software worked as expected 100% of the time, there wouldn't be a need for flash memory, so you can see that there has to be a way to initiate a debug unlock sequence (e.g. via Simplicity Commander) to recover the device. Silicon Labs leaves the bootloader intact after this operation so that you can re-image the device with updated code.

        "But what about the encryption keys or anything else that might be stored in the bootloader space that is critical to product security? If those aren't erased, it would be a simple matter for some ne'er-do-well to use this to create a fake firmware image that allows my valuable software to be stolen," you say.

        While true, the problem here is that you should not be storing hashes or encryption keys in the bootloader space in the first place. As the description of Debug Lock in the Debug Interface chapter of the reference manual explains, "this operation erases the main block of flash, clears all lock bits, and debug access to the Cortex-M4 and bus-system is enabled." Any information that you consider sensitive — firmware, encryption keys, binary image hashes, etc. — must be stored in the main block of flash in order to guarantee that it is erased and thus kept confidential.

        If there is a further concern that, even with proper isolation of encyrption keys and related hashes in main flash block, product security can still be compromised with visibility of the bootloader after debug unlock, consideration should be given to partitioning the bootloader into generic and sensitive components.

        Things like serial communications drivers or flash erase/write routines, generic code for which visibility wouldn't provide a hacker with information that could compromise product security, can be stored in the bootloader space. Sensitive components, say, perhaps, a handler for the firmware update protocol or specific crytographic algorithms, could be stored in the main flash array where they would be securely erased as part of the debug unlock process.