Introduction

Some of our customers may encounter the boot up failure issue caused by unexpected debug lock, unreasonable power supply, EOS/ESD damage, etc.
This KBA sort out a general workflow for customer to troubleshoot this kind of boot up problem during development.

Discussion

Chips have a failure rate measured in 0.0001%. Some failures (extremely low rate) are expected, but excessive failure rates could be the result of a manufacturing issue. For the Failure Rate Estimation of Silicon Labs products, please refer to the Quality and Reliability Report. In this article, a workflow is introduced to check and locate the start-up failure step by step.

The giving flowchart shown above is divided into three parts, corresponding to the recommended process of chip failure analysis.

The first thing to check is software. If the sample applications cannot run properly, hardware need to be verified. If no problems are found during the hardware inspection, an RMA request need to be made to Silicon Labs for further IC failure analysis. Different stages of inspection are described in details in the following sections.

Software

In the first step, we need to narrow down whether the problem is from hardware or software.

To confirm whether a software fault had occurred in the chip, the first step is to flash an example project to see if it can run properly.

EFR32 series of products are similar with EFM32 Series 1 other than EFR32 devices having integrated radios while EFM32 devices do not.

• To test the wireless capabilities of EFR32, you should flash with Wireless example project which can be found from Simplicity Studio.
• To test the peripheral in EFR32/EFM32 devices, you can get MCU example project from peripheral example.

If you run the example projects with no errors, congratulations! Your chips perform well. The problems occurred here might come from your software design and you should debug on your code to locate the issue. If the example project cannot run on your device, take your time. Let's try to figure out the problem step by step.

Software should be compatible with hardware design

Improperly programmed application or incorrect configuration of peripherals can be the cause of unexpected behavior. This is because different hardware design might differ in flash size, GPIO configuration, power supply and so on, which causes incompatible software fails to work.

Note: Please note to use hardware-compatible software designs.

Bootloader missing

If you intend to run a wireless application, it should be noted that Bootloader is required to allow your application to run. Wireless example project in Simplicity Studio do not include Gecko Bootloader by default, so you need to add it separately.

The most reliable method is to build a bootloader for your device using the Appbuilder and flash the generated .s37 or .hex bootloader image file using Simplicity Commander.

Note: Please remember to flash the Bootloader before running a wireless example.

Debugger Connection

To analyze an application to get to the root cause of an issue, it is often very useful to be able to see what is running on inside the software. You can debug your code to see if the program, configuration information, and state variables are correctly written, and monitor the program while it is running.

Sometimes it is possible to lose debug access to the MCU, unintentionally. A few examples include:

• disabling the debug pins
• turning off the HF oscillator the core is running from
• entering EM4

In this case, you can try to execute 'Debug Unlock' or 'Recover bricked device' to regain the debug access. It can be found from the Simplicity Commander Tool. For more details, please refer to KBA Unlock a 'Bricked' EFM32.

If you encounter problems in flashing the firmware, you can also do simple test to determine if the Debug Port is disabled or not. For example, you can open Simplicity Commander to see if you can "Erase chip". You can also use Command-Line Interface to simply dump flash content from Flash to check if it is available to read the Flash.

commander readmem --region <startaddress>: +<length>

If the operation above failed, it could be a problem with debug port design or usage. In this case, please refer to AN958: Debugging and Programming Interfaces for Custom Designs for more details.

Debug Lock

Another possible reason is that debug lock is engaged. There are many reasons why a device maker does not want to allow anyone to dig into the chip and see the application. This prevents attackers from using the debug interface to perform reprogramming the device, interrogating the device, interfering with the operation of the device, etc.

For these reasons, a chip is usually locked down when it leaves production to prevent adversaries from being able to gain access to the chip, often including internal company personnel who want to perform failure analysis.

Three properties govern the behavior of the debug lock.

Using a different set of properties, three different locks can be put on Series 2 debug interface:

Secure Debug Lock is one of the Secure Element Subsystem operations which is dedicated for Series 2 devices. The Secure Element Subsystem of Series 2 devices can be implemented by hardware or software. Please refer to the device reference manual for details.

Note: If your device had engaged with Permanent Debug Lock, it cannot be unlock thus make debug impossible.

For more information about Debug Lock of series 2 devices, please refer to AN1190: Series 2 Secure Debug.

Hardware

If the above software checks have been completed and still fails to locate the problem, then this could be a hardware fault. Next, we will try to figure out the breakdown in hardware.

Failure analysis sometimes goes on to other simple things, including looking for shorts, loose connections or soldering issues. Please carefully check if your board have below behaviors:

• Soldering at wrong profile could lead to delamination issues.
• Tensions in the PCB could crack the package and leads.
• Submersion in liquids could cause formation of metal whiskers leading to shorts.
• Improper handling could lead to ESD damage.
• Sustained operation of IOs outside current / voltage limits over time could alter their characteristics.
• Significant transient voltage overshoot on pads could lead to damage.
• Excessive writes to the same flash regions could wear out specific flash bit-cells.
• Accelerated wear-out due to operation at high temperatures.

If your custom board design haven't been reviewed by Silabs Hardware Engineer, it is highly recommended to apply for hardware review. You can request for support by creating salesforces ticket from Connect Support.

Power supply

An important consideration for all devices is the voltage requirements and dependencies between the power supply pins. The system designer needs to ensure that these power supply requirements are met, regardless of power configuration or topology. Take the EFR32 S2 as example:

• VREGVDD = AVDD (Must be the highest voltage in the system)
• VREGVDD ≥ DVDD
• VREGVDD ≥ IOVDD
• DVDD ≥ DECOUPLE

Please check if the Decouple output for on-chip voltage regulator is normal and ensure there is no power supply voltage dropping below the specs mentioned in the datasheet. The analog peripheral performance of the device is impacted by the quality of the AVDD power supply. The IOVDD pin(s) provide power for all the GPIO pins on the device.

For more details about hardware design considerations, please refer to the document below.

AN0002.1: EFM32 and EFR32 Wireless Gecko Series 1 Hardware Design Considerations
AN0002.2: EFM32 and EFR32 Wireless Gecko Series 2 Hardware Design Considerations

Oscillator

Most microcontrollers can use a crystal oscillator as their clock source. The main advantages of a crystal oscillator are good frequency accuracy, stability, and low power consumption. To solve common problems with crystal oscillators and to achieve high reliability, it is important to pay attention to the configuration used, the components and their values, and the layout. If the oscillator doesn't work properly, it is possible that the selected crystal has poor operating characteristic and is not within the datasheet requirement. Please refer to the table 'High Frequency Crystal Oscillator' in the datasheet as per part number.

The failure of external crystal oscillator may also be the reason for the failure of chip to boot up normally. Please read the documents below for the oscillator design considerations of Silicon Labs EFR32/EFM32 device families.

AN0016.1: EFM32 and EFR32 series 1 oscillator design considerations          
AN0016.2: EFR32 series 2 oscillator design considerations

EOS Damage

An electrical device suffers an Electrical Over-Stress(EOS) event when a maximum limit for either the voltage across, or the current through, or power dissipated in the device is exceeded and causes immediate damage or malfunction, or latent damage resulting in an unpredictable reduction of its lifetime

The most common cause for this (over voltage failure, VDD or Vout is short to ground) is that the VDD exceeded its maximum rating by 0.5V. If either of these events occurs in your system, then an electrical over stress (EOS) has occurred and can cause this type of permanent damage. Please note that this usually happen on a GPIO pin.

To eliminate this issue the best thing to do is determine the source of the event and eliminate it. If not possible, then add transient voltage suppressors as a safeguard.

ESD Damage

When traces from MCU pins are routed to external circuits outside the PCB, to headers or connectors, those traces may experience electrostatic discharge (ESD), latch-up, or even possibly share signals with other systems with no common ground potential (should we move this after the words header or connector). Ensure there are no power (VCC & GND) shorts.

MCU pins can be protected from such conditions in many ways:

• Galvanic Isolation
• Filtering
• Transorb or Schottky Diodes

Each of the above methods of protection and a detailed discussion on latch-up, ESD and ground loops can be found in AN203 in Section 4 'Isolation and Protection'.

Chip Swap

If you have finished checking the possible issue of hardware design, another way to confirm a damage chip is by doing chip swap from your target devices.

RMA (Return Materials Authorization)

If all the above steps are checked out and still cannot locate the problem, you need to start Failure Analysis RMA.

When devices are sent to Silicon Labs for a failure analysis RMA, the devices are tested to determine how and why the devices failed.

The failure analysis application procedures are as follows:
(1) Create salesforce ticket at Contact Technical Support, submit a full description of the problem. The Applications team will review your case and approve your application (If you check all the above steps, still can't find the problem).
(2) Contact with local FAE or sales team to ship your damaged chips.
(3) The failure analysis team will provide a final report after full testing is completed.
(4) Based on the results of the testing, you can contact the application teams for further investigation.

For more details, please refer to Starting an RMA.

During the Failure Analysis procedure, a series of services are provided for test, including but not limited to the following technologies used.

• Acoustic Microscopy
• X-Ray Microscopy
• Decapsulation
• Cross-section
• Curve Tracing

The result of Failure Analysis will be returned in term of "QI-xxxx —— Final Failure Analysis Report". Summary of results are detailed in the report. The following images show some examples of test results.

(1) X-Ray inspection for a normal device

Reference

How to do Failure Analysis on Locked IoT Devices
Quality, Environmental, Supply Chain and Corporate FAQs
Failure Analyses Techniques

This article will be providing a brief overview of the new programming model in Simplicity Studio V5 and provide instructions on integrating peripheral examples available on GitHub into wireless projects with RTOS. Note that this article is using a Bluetooth soc-empty example and the ADC polled example on EFR32BG13. The user is encouraged to apply this to other supported wireless stacks, devices and peripheral examples or custom code.  

Simplicity Studio V5 now has improved resources and GUI tools for embedded application development using EFM32, EFR32 MCU and Wireless MCU devices. Referred to together as Project Configurator and Gecko Platform, these resources are designed to simplify the development process and provide consistency when developing applications for Silicon Labs devices regardless of whether the application is bare-metal or RTOS-based, which radio stack is used and which of the many native software components are utilized. A new development architecture is designed to facilitate and streamline application development. One of the primary elements of this development architecture called Gecko Platform is a suite of embedded software components. It includes high level drivers and services as well as lower level components such as emlib and common utilities. It also encompasses modules such as board level APIs, RTOS, third party libraries and RAIL library.

Project Configurator is a collection of GUI tools available in Simplicity Studio V5 to allow developers to easily integrate and manage different software components from Gecko Platform in their applications. It simplifies the process of adding and removing platform software components in a project. In some cases, the Project Configurator can also be used to configure aspects of these software components or device features. It also includes a pin tool for assignment of peripheral functionality to device hardware pins. 

This article will provide instructions on integrating a peripheral example to a Bluetooth project with RTOS. This article uses Gecko SDK v3.1.1 and is running Simplicity Studio v5.1.1.0. This article pertains only to Gecko SDK versions 3.0.0 and greater. 

Brief Introduction to the Programming Model

The programming model enables the interaction between the Project Configurator GUI tools and the Gecko Platform software catalog.  The programming model is in essence a framework that provides predetermined points of entry for the automatic insertion of initialization code and operational process code. Hooks are provided for platform components as well as custom application code. The configuration tool can generate code that covers hardware initialization, software initialization, and periodic action processing. In addition to this, it also covers both bare-metal and kernel based applications. Using this programming model for user application is important as it will ensure proper hardware initialization and proper SDK software modules initialization. Using this programming model will also ensure proper power management, as power management has to be a centralized service (power requirements can come from different requesters). For more information, refer to - https://docs.silabs.com/gecko-platform/latest/sdk-programming-model. 

In a bare-metal project, the programming model groups firmware actions into an initialization phase and a process action phase. The programming model automatically adapts to the use of RTOS kernel but requires some changes in how the user should include custom application action processing code. More details are provided below - 

Initialization

sl_system_init()

In the initialization phase, gecko platform software modules that have been included in the project through the project configurator are initialized using a call from main to sl_system_init(). This function in turn calls several initialization functions that serve as entry points for the Project Configurator to insert initialization code for installed software components. 

In a project containing a kernel or RTOS, the programming model still contains an initialization phase. However, the function of the initialization phase differs from that of a bare-metal project. When using a kernel, the call from main to sl_system_init() and its nested init calls initialize installed Gecko Platform software modules as well as create RTOS tasks for any system actions that occur at runtime. 

app_init()

This is the entry point for user initialization code. Any initialization code not automatically generated by the project configurator that is used in the application should be inserted by the user such that it is called from within this function. 

In a project containing a kernel or RTOS, the user should also ensure that any custom runtime application actions are handled by a kernel task and should also add these kernel tasks from within app_init(). 

Action Processing

The next phase of the programming model occurs from within the main loop and is responsible for handling all action that the application must process during runtime. Some of the SDK modules (mostly services and wireless stacks) have actions to process periodically. Functions are also provided to help users with that. The action processing differs fundamentally if a kernel application is being used.

sl_system_process_action()

If a software component installed via the project configurator requires action processing, the code to do so will automatically be inserted and called from sl_system_process_action() function and the nested process action calls within this function. 

app_process_action()

After sl_system_process_action() returns, app_process_action() is called from the main loop. This function is the entry point for custom user runtime actions and users should place function calls to custom application code here. 

sl_system_kernel_start()

In the kernel programming model, autogenerated system actions and custom application actions are handled by kernel tasks added during the initialization phase. The main function then calls sl_system_kernel_start() which starts the kernel scheduler. Any system or custom application runtime actions registered as tasks during the initialization phase will execute according to the RTOS scheduler. 

Note: The SDK component catalog is a simple header file named sl_component_catalog.h that can be included from anywhere in the project. This file contains #define entries for the different SDK components available in the project. This allows users to enable/disable portions of code depending on whether an SDK component is present in the project or not.

Incorporating a Peripheral Example into a RTOS-based Wireless Project

Adding RTOS to a Wireless Project

Refer to the instructions provided in AN1260 to integrate RTOS into a Wireless Project. This article assumes that that the user has imported soc_empty Bluetooth example project and has created the tasks required to integrate an application into a Bluetooth project (section 3.3 in the Application Note).

NOTE: This article uses FreeRTOS, but either the FreeRTOS or Micrium Kernel will work with the provided application code. To switch to the Micrium OS follow the Micrium OS specific instructions provided in AN1260.

Peripheral Example Integration

Before integrating the peripheral example, the user needs to make sure that the previous section (adding RTOS to a Wireless Project) has been completed. The ADC Single Polled example code provided in our GitHub repository will be used to populate the necessary functions within the Bluetooth+RTOS application to take a software triggered measurement of an expansion header pin voltage. Similar steps can be followed for other peripheral examples or custom application code to integrate into RTOS-based Wireless Project. 

A. From the Simplicity IDE perspective and while viewing soc_empty.slcp in the main window, navigate to the "Software Components" tab. 

B. In the project configurator, the software components tab allows users to install and uninstall components as well as configure components that support customization (configurable components have a gear symbol next to the component name). In the left pane of the software components tab, users can browse categories of components. Categories can then be expanded to view individual component. From here, install the following Software Components (if not installed already):

1. Platform > Peripheral > ADC

This will add the necessary source files from the emlib library which is required for running code provided through our Peripheral Examples repository on GitHub.

NOTE:

• When a component is installed, the corresponding SDK files are copied/linked into the project folder, all dependencies of the component are copied into the project folder and new include directories are added into the project settings. In addition to this, configuration files are copied into the config folder and corresponding autogen files are modified in the autogen folder to integrate the component into the application. 
• Several filters and a keyword search are provided to help explore component categories.

C. Here's the code from the ADC Single Polled example taken from the peripheral example 

D. Now, the code shown above must be split to match the programming model of the project in Simplicity Studio V5. In other words, the ADC initialization and ADC process action should be moved to appropriate APIs in the Gecko Platform project. In the "Project Explorer" window, open app.c. This article will be creating new subroutines for initialization, single conversion start and conversion complete in app.c file. Specifically - 

1. Include em_adc.h and em_cmu.h at the top of the file
2. Copy or add the definition of adcFreq and declare sample and millivolts global variables at the top of the file
3. Create a function called my_adc_init() and copy the initialization code from step #3's initADC() function
4. Copy or add the ADC single conversion start function to my_adc_start_measurement()
5. Copy or add the code polling the ADC status and then retrieve the single conversion to my_adc_measurement_get()

NOTE: 

1. The ADC measurement is split in this example into two functions, one to kick off a conversion, and another to retrieve the conversion data, however the two could be combined. The benefit of splitting this up is while the ADC conversion is taking place, other code can be executing.
2. It is up to the user to decide if they'd like to split this into different demo.c/demo.h files or directly paste it into app_init() or app_process_action().

E. Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again. 

1. In app_init(), add the ADC initialization function my_adc_init(). This now creates a kernel task to handle the ADC measurements. 
2. Add the ADC conversion start and measurement functions to the kernel task. For more information about adding application tasks to a Bluetooth project, refer to section 3.3.3 in AN1260. 

F. Build the project and flash it on the WSTK. Set a breakpoint in my_adc_measurement_get() function and observe/confirm that it periodically gets triggered.

NOTE: The user can also add the IO Stream component to print the ADC values, but this implementation is outside the scope of this article. For more information on IO Stream, please refer to - https://docs.silabs.com/gecko-platform/latest/service/api/group-iostream. 

Within the EFP01 family, only EFP0108, EFP0109, EFP0110, EFP0111 can be used as a Boost converter for an application that has source voltage less than the desired load voltage. Out of all available OPNs, there are only two development boards – BRD8100A [EFP0108] and BRD8100B [EFP0111] currently available that can be used to develop such an application.

If the user wants to develop an application for EFP0109 but is interested to test his proof of concept before prototyping, the user can use BRD8100A to approximate EFP0109 along with the hardware and software modifications explained in Case 2 of this KBA.

Case 1 [0.8V < Vin < 1.8V]

For source voltage less than 1.8V, BRD8100A (EFP0108) can be used with the following steps:

Step 1: Power VIO by connecting the USB cable to the reference board.

Step 2: Connect VIN (0.8V to 1.8V) through an external source or connect onboard a low voltage regulator by shorting ST208.

Step 3: Using Simplicity Studio – EFP Configuration Tool, load the desired register settings to the device.

Step 4: Connect load at the VOA terminal.

Case 2 [1.8V < Vin < 3.6V]

For source voltage more than 1.8V, the hardware of BRD8100A (EFP0108) can be modified similar to connections of EFP0109 with the following steps:

Step 1: Remove R201, R202, R203, R204, R205, R206.

Step 2: Connect R207

Step 3: Connect VDDB to VIN or LA2

Step 4: Connect external Host MCU using P202 and an additional common GND pin. Please note that external Host MCU such as EFM32/EFR32 starter kit will be required to program correct register settings into the EFP0108 after the initial start-up sequence.

Step 5: Create any sample project in Simplicity Studio 5 to utilize the existing I2C firmware, add software component of EFP01 instance to the project. Create a new function for EFP01, create new handle, initialize the EFP and add the following C code to the sample project:

sl_efp_write_register(efp, EFP01_I2C_CTRL, 0x09);

sl_efp_write_register(efp, EFP01_CC_CTRL,0x68);

sl_efp_write_register(efp, EFP01_EM_CRSREG_CTRL,0xE8);

sl_efp_write_register(efp, EFP01_VOA_V,0x34);

sl_efp_write_register(efp, EFP01_VOC_V,0x05);

sl_efp_write_register(efp, EFP01_VOB_EM0_V,0xAF);

sl_efp_write_register(efp, EFP01_VOB_EM2_V,0x2F);

sl_efp_write_register(efp,EFP01_BIAS_SW,0x0F);

sl_efp_write_register(efp, EFP01_BB_IPK,0x6C);

sl_efp_write_register(efp, EFP01_BB_CTRL3,0x17);

sl_efp_write_register(efp, EFP01_BB_CTRL5,0x9B);

sl_efp_write_register(efp, EFP01_BB_CTRL6,0x02);

sl_efp_write_register(efp, EFP01_LDOB_CTRL,0x0C);

sl_efp_write_register(efp, EFP01_LDOC_CTRL,0x8C);

sl_efp_write_register(efp, EFP01_LDOC_BB_CTRL,0xF0);

sl_efp_write_register(efp, EFP01_BK_CTRL0,0x00);

sl_efp_write_register(efp, EFP01_BK_CTRL1,0xFC);

sl_efp_write_register(efp, EFP01_BK_IPK,0x6C);

sl_efp_write_register(efp, EFP01_BK_CTRL2,0x50);

sl_efp_write_register(efp, EFP01_ADC_CC_CTRL,0x3F);

sl_efp_write_register(efp, EFP01_ADC_LIMITS,0x18);

Note that custom applications may have different register settings requirements than what is recommended above. Hence correct register values should be set by referring to the latest revision of the EFP01 datasheet.
The above settings will configure the outputs to the following voltages:
VOA = 3.33V
VOB = 1.17V
VOC = 1.86V

The maximum output voltage obtained at VOB will be limited to 1.2V rather than 3.3V as on EFP0109 due to the physical limitation and presence of EFP0108 on the development board.

Step 6: Power VIO from the external MCU board.

Step 7: Connect VIN (1.8V to 3.6V) through an external source.

Step 8: Load the register settings of EFP0108 using an external MCU.

Step 9: Connect the load at the VOA terminal.

Question

Are CSLIB, CAPSENSE, and CSEN the same, an which one should I be using for my application?

Answer

These concepts are sometimes used “interchangeably” by customers trying out our development boards, leading to confusion and communication issues. The following KBA aims to provide an introduction to these terms as well as relevant documentation sources if deeper knowledge is required.

From a higher to a lower level, these are the different definitions:

1. CSLIB

CSLIB is a set of source code and pre-compiled libraries that demonstrate the capacitive sensing functionalities of our devices. At its core, CSLIB can configure and manage multiple low-level peripherals of our MCUs such as ACMP (Analog Comparator), LESENSE (Low Energy Sensor Interface), and CSEN (Capacitive Sense Module).

The sensing technique used in our CSLIB development board examples is dependent on the target device and its available peripherals, e.g., for the SLSTK3402A (EFM32PG12) the CSEN peripheral is used. Other starter kits such as the STK3700 (EFM32GG) didn’t have the CSEN peripheral, therefore, relied on the ACMP (and LESENSE in some instances) for this. We have a KBA that has a small breakdown table on the CSLIB implementation for different STKs.

The CSLIB can operate in conjunction with a Simplicity Studio tool called Capacitive Sense Profiler. Access to the source code of CSLIB is limited, due to the pre-compiled libraries, but the EMLIB implementation (MCU peripherals) is accessible. The available source code can be checked in the Simplicity Studio installation path:

<STUDIO_SDK_LOCATION>\platform\middleware\cslib

STK CSLIB examples can be found in the following path, under the name "KITNAME_cslib".

<STUDIO_SDK_LOCATION>\app\mcu_example\KIT_NAME\cslib

For STKs that rely on the ACMP for capacitive sensing measurements, the CSLIB leverages not only the EMLIB peripheral APIs but also the CAPSENSE driver.

Other relevant CSLIB documentation can be found in the following links:

• CSLIB library documentation
• Application notes
  • AN0829
  • AN0828

2. CAPSENSE

CAPSENSE is a development kit driver used to evaluate capacitive sensing but, contrary to CSLIB, it doesn’t implement any pre-compiled libraries, it instead leverages the EMLIB API for the ACMP peripheral for capacitive sensing. The pins are routed through the APORT (analog port) to the ACMP for measurement purposes.

STK CAPSENSE examples can be found in the following path, under the name "KITNAME_touch".

<STUDIO_SDK_LOCATION>\app\mcu_example\KIT_NAME\touch

We have an application note for series 0 devices that explains how ACMP and LESENSE are used for capacitive measurements:

3. CSLIB vs CAPSENSE

The main difference between CSLIB and CAPSENSE is how the capacitive measurements are performed. In the case of CSLIB it will be based on the available technique in the target STK (CSEN, ACMP+LESENSE, or ACMP). CAPSENSE uses ACMP exclusively. In the case of the STK3402A where both ACMP and CSEN peripherals are available, the available CSLIB example uses the CSEN peripheral but it’s possible to perform the capacitive measurement with any of the 2 peripherals.

The decision of which one to use will be ultimately based on your needs and of course available peripherals.

4. What is EMLIB?

EMLIB is a series of APIs developed to provide customers with a software layer to access the peripherals of the MCU. This is the closest to direct register access that we have. Every peripheral of an MCU is covered through a specific EMLIB API. The documentation for all of them can be found in the following link.

EMLIB is usually implemented in all the middleware or high-level drivers developed for our development kits (such as CAPSENSE and CSLIB).

4.1 CSEN and ACMP

CSEN and ACMP are both peripherals of our MCUs. The CSEN peripheral was designed specifically for capacitance to digital conversions whereas ACMP was developed to work with all kinds of analog inputs. The best way to understand a peripheral is usually through consultation of the corresponding chapter in the reference manual and cross-referencing with our peripheral examples.

Note that our peripheral examples repository doesn’t have an example for the CSEN peripheral, but its implementation can be abstracted from the CSLIB examples.

References

[1] https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2017/04/13/capacitive_senselib-xKyg

[2] https://docs.silabs.com/gecko-platform/latest/middleware/api/group-cslib-group

[3] https://www.silabs.com/documents/public/application-notes/AN0829.pdf

[4] https://www.silabs.com/documents/public/application-notes/an0828-capacitive-sensing-library-overview.pdf

[5] https://www.silabs.com/documents/public/application-notes/an0028-efm32-lesense-capacitive-sense.pdf

[6] https://docs.silabs.com/gecko-platform/latest/emlib/api

[7] https://github.com/SiliconLabs/peripheral_examples

Question

Is it possible to implement conditional compiling in my source code so that it works for specific families?

Answer

Yes, our source code implements a series of define macros that can be leveraged to achieve this functionality. This technique is already used across multiple EMLIB modules to provide compatibility with multiple target devices. It can be useful in cases where a single source code file is to be used with multiple targets, but different functionalities are required.

It’s important to note that when building an MCU project with the Simplicity Studio IDE, the desired target architecture needs to be selected so that the relevant header files for the device are included in the project. The use of conditional compiling macros doesn’t override this functionality and it’s simply to allow a single source code file to be used across projects with different target architectures.

The necessary macros are found inside the header file containing the header file of the specific device usually located in the following path:

• <STUDIO_SDK_LOCATION>\platform\Device\SilionLabs<Desired device family>\Include
• e.g: \platform\Device\SiliconLabs\EFM32GG11B\Include\efm32gg11b820f2048gl192.h

Look for the “Part Family” define group. The relevant macros are highlighted in yellow in Figure 1 below:

Inside your source code, you need to implement a structure such as the following to determine a code snipped that will be conditionally compiled:

#if (defined(_EFM32_GIANT_FAMILY) && defined(_SILICON_LABS_32B_SERIES_1_CONFIG_1))
/* Conditionally compiled user code */
#endif

The same structure applies for Series 2 devices, only the “config” macro needs to be updated to the series 2 version. As for Series 0 devices, the “config” macro is not available, therefore, the “_SILICON_LABS_32B_SERIES_0” macro should be implemented instead. For example, for the Giant Gecko Series 0 family see the snippet below:

#if (defined(_EFM32_GIANT_FAMILY) && defined(_SILICON_LABS_32B_SERIES_0))
/* Conditionally compiled user code */
#endif

Attached to this KBA you can find a simple source code file that works with the SLSTK3700 and STK3701A development kits (Giant Gecko series 0 and 1 respectively). It’s a modified version of the “Blink” example and it integrates the macros to conditionally compile a different delay value for each board and to enable the DCDC converter in the STK3701A.

At a high level, the EFR32 series 1 chip has two major blocks: MCU + Radio.

By default, most of the applications use EFR32 series 1 chip for both its MCU and radio functionality, but there are certain applications where the designer might want to use the EFR32 chip as an MCU only device i.e. without radio functionality. A reason for such usage would be due to some features that other MCUs might not have or to simply keep the application future proof with the possibility of wireless capability.

In the case where the radio is not used, special care needs to be taken to connect and configure the part properly. 
The table below provides a comparison of generic pin connections for the standard EFR32 with radio used versus the non-radio use case:

* Please note that even if the Radio block of the EFR32 chip is not used, DC voltage should be supplied at the appropriate power supply (PAVDD, RFVDD) pins along with the respective filtering components. A detailed pin connection and filtering component information are given in AN0002.1.

REMINDER:
The EFR32 Series 1 Supply constraints are as follows:-

• AVDD must be the highest voltage in the system
• VREGVDD must be connected to AVDD on DCDC-enabled devices
• AVDD >= DVDD
• AVDD >= PAVDD ( For 2.4GHz or Dual-band devices, PAVDD refers to the device pin. For sub-GHz devices, PAVDD refers to the external power amplifier supply)
• AVDD >= RFVDD
• AVDD >= IOVDD
• DVDD >= DECOUPLE

The purpose of this knowledge base article is to demonstrate the usage of the Giant Gecko GG11 started kit to implement a sound-based guitar and ukulele tuner. A small background on instrument tuners is provided followed by a brief description of the hardware used from the development board and its implementation through functional blocks. Lastly, the general description of the software workflow is discussed. The article includes the simplicity studio project (.sls), please refer to it and it’s readme file for details on the software implementation and how to run the application. The following KBA contains a series of steps on how to import .sls files into Simplicity Studio.

1. Introduction

An electric tuner aims to measure the frequency of a note played by an instrument, this is then correlated to its associated musical note in a scale, and feedback is provided to the user of the “closeness” of the played note to the desired one, usually in a visual way.

Tuners may record the input note by different means, usually through direct connection by an input jack, by sound (using a microphone) or by vibration (using a piezoelectric sensor).

Lastly, a tuner may be classified as standard or chromatic, the former allows to tune an instrument to its standard notes and the later will display the tuning at any pitch on a 12-notes chromatic scale. This project follows a sound approach with standard tuning for guitar and ukulele.

2. Hardware implementation

This example is implemented in the SLSTK3701A starter kit for the EFM32GG11 MCU. Multiple on-board hardware elements are leveraged such as the MEMS microphones, push-buttons, and LCD screen; MCU peripherals such as the PRS, GPIO interrupts, USART (I2S mode), CMU and LDMA. Core-specific peripherals like the DSP, FPU, and NVIC are also utilized.

Figure 1 below shows a high-level functional block representation of the project, each block is marked by a green background.

3. Functional blocks

3.1 Input detection

The tuner interacts with 3 different inputs: one audio and two mechanical. The audio input is captured by the 2 MEMS microphones in the SLSTK and the mechanical ones by the two available push-buttons.

3.1.1 Audio Input

The on-board microphones generate a PDM (Pulse Density Modulation) signal as its output, given that the MCU has no specialized peripheral for this, an IC transducer/codec is implemented. The codec is routed to the USART 3 peripheral of the MCU that can be configured to operate in I2S mode. This implementation is observed in Figure 2 below.

According to the microphone’s datasheet, the microphone operates in 3 different states based on the VDD value and the frequency of the input clock. A high value in VDD and a frequency >= 1 Mhz will take the device to an active mode whereas a frequency < 1Khz will take it to a sleep mode.

The clock signal for the microphones (PDM_CLK) is generated by the codec which requires 2 clock inputs the “bit clock” (BCLK) and the “word select” or “left-right clock” (LRCLK).

• “Bit clock”: Pulses once for each data bit in the data line, relative to the baud rate of  the I2S peripheral

• “Left-right clock”: Determines the sampling rate, and the channel that data comes from, generated by the CS (Chip select) of the peripheral
  • High: Right channel
  • Low: Left channel

According to the datasheet of the codec, BCLK should be at least 64x the LRCLK rate and the generated PDM_CLK will be 64x the LRCLK rate. Furthermore, it’s stated that the minimum sampling rate should be between 4 - 96 kHz leading to a PDM_CLK ranging from 256 kHz to 6.144 MHz.

Since the PDM_CLK should be at least 1 MHz, the LRCLK should be PDM_CLK/64 or 15.625 KHz. Still, during testing, it was determined that pushing the LRCLK rate as low as 2 kHz still rendered reliable results this is important for the resolution of the application as explained in the Frequency acquisition section.

Following the selected sampling rate as 2 kHz, word size of 32-bits, and 2 channels, the Bit clock or baud rate is determined to be 2000 x 32 x 2 or 128000 bits/s.

It’s important to note that the data from both channels (left and right) is transferred through the same data line, and the application should keep track of the source in the RX buffer, this is described in the Data transfer section.

3.1.2 Mechanical inputs

The SLSTK has 2 push-buttons available for user interaction. Push-button 0 is used to initialize the tuner whereas push-button 1 is used to switch between target instrument (Guitar & Ukulele) once the tuner is operating. Each input is managed in different ways, button 0 is routed to the PRS (Peripheral Reflex System) peripheral, and button 1 is managed through the edge interrupt of the GPIO peripheral.

The PRS system allows routing an event in a peripheral (producer) towards another peripheral (consumer), in this case, the GPIO level change towards the USART peripheral enabling its RX and TX components. This is done without the CPU intervention allowing the system to stay in a low energy mode. Further details on the PRS and GPIO peripherals can be found in sections 15 and 34 of the EFM32GG11 reference manual.

3.2 Data transfer

Following the idea of low energy mode, the LDMA (Linked Direct Memory Access) peripheral is enabled to transfer the microphone data in the RX buffer of the USART to RAM without the need for the CPU. Upon a transfer request the LDMA uses the descriptor data in memory to perform its operations, an extra property is that descriptor may link to new ones with different properties allowing for different operations on each transfer or looped process, which is the case of this example.

The LDMA peripheral is configured to trigger peripheral to memory transfers based on the RXDATAV and RXDATAVRIGHT USART status flags, the former indicates that data is available in the buffer and the second that data from the right channel is available allowing to differentiate between channels. The DMASPLIT in the USART_I2SCTRL register should be enabled to allow channel differentiation.

For this application only the data from the left microphone is used, still, the transfers for both channels are implemented for scalability. The left channel transfer has two linked descriptors assigned each with its own target buffer and the following main properties:

• 1 byte-sized transfers
• Total transfers (in bytes) = 4 x buffer size (uint32_t buffers)
• Interrupt generated on descriptor completion (full buffer)
• Looped linkage between descriptors

The right channel transfer descriptor performs a single byte transfer to a dummy buffer with no interrupts generated.

3.3 Processing

Once data from the microphone has been captured and the CPU informed, the processing begins which can be divided into three main steps: raw data processing, frequency acquisition, and tuning algorithm.

3.3.1 Raw data processing

This segment manages and adjusts the microphone data before it’s processed for frequency extraction.

• Determine the data buffer to process
  • There’re 2 buffers available for the left channel in the application
• Match the endianness of the data and adjust the number of bits
  • Incoming data is big-endian whereas the MCU is little-endian. Only 20 bits of data are >relevant according to the codec datasheet

3.3.2 Frequency acquisition

This segment determines the main frequency component of the input signal leveraging the CMSIS-DSP library that provides a series of functions for signal processing.

• Apply a Hanning window to the data
  • Non-integer periods of data generate undesired high-frequency components after FFT processing, more details can be found in the following link
  • Hanning window coefficients are generated in code (arm_cos_f32)

• Perform an FFT on the data (arm_rfft_fast_f32)
  • The resolution of the FFT will be dependent on the sampling frequency and the number of FFT elements. Also, the frequency bin range is half of the sampling frequency

• Get the magnitude of the real and imaginary pairs from the FFT (arm_cmplx_mag_f32)
• Determine the bin with the highest magnitude (arm_max_f32)
• Verify if a second harmonic was detected
  • Magnitude comparison of the highest bin and that at half of the frequency
• Determine the frequency of the input

3.4 Tuning algorithm

This is a simple heuristic algorithm that compares the detected frequency with a series of frequency brackets surrounding a target fundamental frequency. The targets are dependent on the selected instrument and correspond to the frequencies of each string when tuned, these values are hardcoded and adjusted to the nearest integer that can be detected based on the resolution of the FFT. For the example code, this resolution is 3.91 Hz per frequency bin. Figure 3 below shows a graphic representation of the frequency brackets.

Based on the bracket, the algorithm will determine the properties of the figures and text to be displayed on the LCD screen in the last functional block.

3.5 Feedback

The LCD screen management is leveraged through the GLIB (Graphics Library) As mentioned before, depending on the bracket that the detected frequency falls, a different set of properties are defined and used to display specific figures related to the “tuning level” detected. Figure 4 below shows an example of the 3 cases portrayed in Figure 3.

Please refer to the following KBA for and introductory documentation on using the GLIB library.

4. Software flow

The application begins by initializing the different MCU peripherals as well as the 3 flow control flags:

• “buffer_select” - Indicate the buffer to be processed
• “buffer_ready” - Indicate that a buffer is ready to be processed
• “instrument_toggle” – Indicate the instrument that is being tuned (guitar or ukulele)

An initial interface screen is displayed, and the processor goes to EM1 (Energy Mode 1). The data acquisition and processing begin until button 0 is pressed, from this point, the application will run continuously until the board is reset.

Once push-button 0 is pressed, a PRS signal enables the I2S RX and TX components allowing microphone data to be captured, this in terms begins the LDMA transfers and once a full transfer is complete (a buffer of data is ready) an interruption is generated toggling the “buffer_select” flag and making the system leave EM1. Pressing push-button 1 will also take the system out of EM1 although its real purpose is to control the “instrument_toggle” flag.

Once a buffer of data is ready, the filled buffer (out of the two available) is selected based on the “buffer_select” flag. Its contents are pre-processed and the frequency analysis is performed as described in the Processing section.

Once the frequency is known, based on the “instrument_toggle” flag, the adequate tuning algorithm is executed either guitar or ukulele. They both have the same heuristic nature each differing on the target frequencies. This algorithm will define a series of properties that are passed as a structure to the LCD updating routine.

After the LCD update, the “buffer_ready” flag is cleared indicating that a new buffer may be processed. It’s important to note that I2S data acquisition and LDMA transfers are still running in the background during the data processing cycle. Figure 5 below demonstrates the overall software operation in a graphical manner.

References

[1] https://www.silabs.com/community/software/simplicity-studio/knowledge-base.entry.html/2018/09/26/exporting_importing-IEqP

[2] https://www.silabs.com/documents/public/reference-manuals/efm32gg11-rm.pdf

[3] https://arm-software.github.io/CMSIS_5/DSP/html/index.html

[4] https://download.ni.com/evaluation/pxi/Understanding FFTs and Windowing.pdf

[5] https://docs.silabs.com/mcu/latest/efm32gg11/group-glib

[6] https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/08/21/using_the_lcd_screen-UW7Q

Question

How do I use the alternate excite pin for LESENSE excitation in series 1 devices?

Answer

There are a total of 16 channels in the LESENSE peripheral, and there are 8 alternate excitation pins. Each alternate excite pin is mapped to Channel X and Channel X + 8 with 0 < X < 8. For pin mapping of each device, please refer to the Alternate Functionality Overview section in the device's datasheet.

In order to use the alternate excitation pin, add the following sequence into the LESENSE initialization routine:

1. Set ALTEX to true in the LESENSE_CHx_INTERACT register (x being the channel number you want to configure).

2. Set ALTEXMAP to ALTEX in the LESENSE_CTRL register.

3. Enable the corresponding channel pin (CHxPEN) and Altex pin (ALTEXxPEN) in LESENSE_ROUTEPEN register.

4. Configure the LESENSE_ALTCONFIG register for desired setting (check register description in the reference manual for more information).

5. Make sure the corresponding GPIO pin for alternate excite is set to push-pull output if the excitation type is logical low or logical high.

You should be able to see the excitation pulse in the alternate excite pins with these configuration added.

An example of using LESENSE excitation pin is attached in this article. The example runs on an EFR32MG12 starter kit and the excitation pulse is on PA8, which is the alternate excitation pin for LESENSE channel 0 on EFR32MG12. The code added to enable alternate excite is:

  LESENSE -> CTRL |= LESENSE_CTRL_ALTEXMAP_ALTEX;
  LESENSE -> ROUTEPEN |= LESENSE_ROUTEPEN_ALTEX0PEN | LESENSE_ROUTEPEN_CH0PEN;
  LESENSE -> CH[0].INTERACT |= LESENSE_CH_INTERACT_ALTEX;
  LESENSE -> ALTEXCONF |= LESENSE_ALTEXCONF_IDLECONF0_LOW;

Introduction

EFR32 devices allow the JTAG TDI/TDO pins to be used for other functions when not needed for JTAG debugging. Under certain circumstances, such as an unexpected reset during debug, control of these pins can unexpectedly be transferred to the debug peripheral. On Series 2 devices this happens more frequently due to changes in the reset topology. In such cases, the device must be reset again to regain normal control over the pins.

Background

JTAG and SWD

EFR32 supports debugging through either the JTAG or the SWD protocol. The JTAG protocol is an industrial standard for testing and verifying PCBs that utilizes 4 pins; TCK, TMS, TDI and TDO. SWD is an ARM proprietary protocol that is interoperable with a JTAG test environment, but utilizing only two pins, the TCK and TMS pins.

Debug Port

The Serial Wire/JTAG Debug Port (SWJ-DP) is responsible for implementing both the JTAG and the SWD interface. The SWJ-DP also facilitates for switching between the two protocols on demand.

The SWJ-DP allows a designer to allocate the JTAG TDI and TDO pins to other functionality, such as GPIO, when only using the SWD interface. 

On startup the SWJ-DP will, for compatibility reasons, default to JTAG mode. In order to switch to SWD mode, a debugger will have to transmit a specific initialization sequence on the TCK and TMS pins. This initialization sequence is designed such that it will not affect any JTAG devices on the same bus.

JTAG-on-demand

JTAG-on-demand is an EFR32-specific feature that allows an EFR32 device to appear as defaulting to SWD mode. This means that the TDI and TDO pins are allocated as normal GPIO at startup instead of being allocated to the debug interface.

JTAG-on-demand will reallocate the TDI and TDO pin to the debug interface when the SWJ-DP is in JTAG mode and detects JTAG traffic. Once JTAG-on-demand has been activated, it will not be deactivated until the next full reset of the chip (and debug interface).

JTAG-on-demand can be overridden by writing to the GPIO.DBGROUTEPEN register. Attempting to write the relevant bits while the debug circuitry is active will cause a BusFault on Series 2 devices.

Series 2 reset topology

EFR32 Series 2 devices have a different reset topology than EFR32 Series 1 devices. The most notable change is that in Series 2 devices the debug interface is reset on assertion of the RESETn pin.

Error Conditions

If anything except the full SWD initialization sequence is received by the EFR32 on the debug interface while the SWJ-DP is in JTAG-mode, JTAG-on-demand will activate and transfer control of the TDI and TDO pins to the SWJ-DP.

When control of the pins has been transferred, the pins cannot be used in any other function, including normal GPIO, SWO or ETM Trace.

There are two scenarios in which loss of control over TDI and TDO is likely to occur:

• If the EFR32 is reset in a way that causes the debug interface to be reset while there is an active SWD debug session. For Series 2 device, this includes reset via the RESETn pin. The debug adapter will be unable to detect this reset in all circumstances, causing the debug adapter to continue communicating over SWD, activating the JTAG-on-demand feature.
• If the debug adapter attempts to initialize the SWD connection before the EFR32 has fully exited reset so that the SWD initialization sequence is not registered. This causes JTAG-on-demand to activate when verifying the connection as required by ARM.

While it is possible for this to occur on EFR32 Series 1 devices, it is a lot easier to trigger on Series 2 devices due to the change in reset topology. It is also not possible to override the JTAG-on-demand feature on Series 2 devices, contrary to Series 1 devices where this is possible.

Consequences

When JTAG-on-demand is activated on an EFR32 Series 2 device, the following will happen

• SWO will stop working
• ETM Trace will stop working
• Loss of control over GPIO pins PA3/PA4

For Silicon Labs development kits, the following are features that can be affected depending on what is connected to PA3/PA4:

• VUART
• Simplicity Studio Code Correlation
• External SPI Flash
• VCOM Flow Control (CTS always high)
• Button stuck high

Workaround

Once the condition occurs, the only known workaround is to disconnect all active debug sessions, reset the target through the RESETn pin or toggling power.

Glossary

Question

How to print messages to Virtual COM port by using printf() function in an MCU application?

Answer

We provide so called RETARGET functions with the aim of avoiding the needs of the low level UART peripheral configuration. The following step-by-step guide shows how to add all the necessary files and functions to a project from the scratch.

1. Create an empty MCU project

File -> New -> Project...

Figure 1.
Create an empty MCU project.

2. Copy (or link) the following emlib and RETARGET files

emlib from "<StudioPath>\v4\developer\sdks\gecko_sdk_suite\v2.7\platform\emlib\src":

• em_cmu.c
• em_core.c
• em_gpio.c
• em_usart.c

RETARGET from "<StudioPath>\v4\developer\sdks\gecko_sdk_suite\v2.7\hardware\kit\common\drivers":

• retargetio.c
• retargetserial.c

Figure 2.
Files in the project.

Note: The header files are added to the Include path by default, therefore no need to add them manually.

3. Place the RETARGET functions

The Starter Kits have a bidirectional analog switch between the MCU and the Board Controller.
The VCOM_ENABLE pin should be in high logical state for allowing the data flow through to the board controller.
Find the given pin in the User's Guide of the kit.

Figure 3.
Virtual COM Port Interface.

To realize this setting, add the below lines prior to call the RETARGET functions.
Additional headers added:

    #include "em_cmu.h"
    #include "em_gpio.h"
    #include "retargetserial.h"
    #include "stdio.h"

and place the following code after the CHIP_Init()

  //Enable GPIO clk prior to write its registers  
  CMU_ClockEnable(cmuClock_GPIO,true);

  //Enable the switch with VCOM_ENABLE pin, see User's Guide of the board
  GPIO_PinModeSet(gpioPortA,5,gpioModePushPull,1);

  RETARGET_SerialInit();
  RETARGET_SerialCrLf(1);

  printf("VCOM is working!\n");

4. Start a terminal emulator

Used serial port can be determined by Device Manager:

Figure 4.
Device Manager.

5. Build and download the image

Figure 5.
Terminal on Host PC.