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.
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.
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.
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.
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.
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.
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:
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.
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.
|Property||Description IF Set||Default Value|
|Debug Lock||The debug port is kept locked on boot.||False (Disabled)|
|Device Erase||The Device erase command is available.||True (Enabled)|
|Secure Debug||Secure debug unlock is available.||False (Disabled)|
Using a different set of properties, three different locks can be put on Series 2 debug interface:
|Secure Debug||Device Erase||Debug Lock||Description|
|Standard Debug Lock||Disabled||Enabled||Standard||The Device erase command will wipe the main Flash and RAM, and then a reset will yield an unlocked device.|
|Permanent Debug Lock||Disabled||Disabled||Permanent||The part cannot be unlocked. Devices with Permanent Debug Lock engaged cannot be returned for failure analysis.|
|Secure Debug Lock||Enabled||Disabled||Secure||Secure debug unlock is enabled, which makes it possible to securely open the debug lock temporarily to reprogram or debug a locked device.|
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.
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:
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.
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:
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.
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.
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.
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:
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'.
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.
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.
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
(2) EOS damage was observed via Decapsulation analysis
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 v18.104.22.168. This article pertains only to Gecko SDK versions 3.0.0 and greater.
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 -
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.
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().
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.
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.
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.
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.
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.
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):
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.
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 -
E. Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again.
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.