Member | Action | Date |
---|---|---|
![]() |
Updated
RMU_E103 POR/BOD Reset Issue on Knowledge Base
Questions: A. What is Errata RMU_E103 B. What devices are affected? C. How can I prevent this issue from affecting my application? D. Are there plans to fix this issue?
Answers: A. Erratum RMU_E103 describes an issue with certain Series 0 EFM32 devices. Affected parts see a gap in the coverage of the brown-out and power-on reset sources around 1.3V . The exact gap in reset coverage will be part specific if present at all. If an affected device is operating in this problematic VDD range, the device will attempt to start up while well below the tested supply voltage for the microcontroller. The device takes a short amount of time to start up. For a typical part at normal voltages this is 163 µS. If the startup succeeds, the device will then attempt to execute code, but may not be able to do so at low voltage. At this low voltage neither a successful startup or successful code execution is guaranteed. Note that during fast voltage ramps, e.g. power-on and power down events, VDD will not be at a problematic voltage long enough for the device to start up. However, if VDD is held at around 1.3V for a sufficient duration, the device may enter this undefined state where code is being executed below tested voltages. The workaround to this issue is to assert a pin reset during the low VDD event. If a pin reset is asserted, the device cannot attempt to start up. The reset pin should be driven low prior to VDD falling below the BOD reset threshold.
B. RMU_E103 is an erratum that effects some devices from the following EFM32 Series 0 products:
This erratum does not affect EFM32 Gecko, Giant gecko, or any EFM32 Series 1 devices.
C. Steps can be taken to both detect if RMU_E103 is occurring on a specific device, and to prevent code from executing at low voltage.
Figure 1. VDD Test for RMU_E103 Current Consumption
D.
A production screen has been implemented for EFM32 Tiny Gecko that catches devices susceptible to this condition and is implemented on material with date code 1909 and later. Silicon fixes are planned for the remaining devices.
|
Mar 04 2019, 3:30 PM |
![]() |
Updated
RMU_E102 POR/BOD Reset Issue on Knowledge Base
Questions: A. What is Errata RMU_E102? B. What devices are affected? C. How can I prevent this issue from affecting my application? D. Are there plans to fix this issue?
Answers: A. Erratum RMU_E102 describes an issue with certain Series 0 EFM32 devices. Affected parts may see voltage regulator failure when subjected to the following scenario:
In this type of sequence mentioned above , the voltage regulator may fail to re-initialize. If this occurs, the DECOUPLE pin will continue to decay to 0V, even after VDD has recovered. In this state, the core logic is not powered, and the device will be unable to execute code or respond to a pin reset. An affected device will successfully recover from this state if power cycled. Additionally, if a pin reset is applied prior to the Brown out detector (BOD) asserting reset, the regulator will always re-initialize successfully. The BOD threshold varies between 1.74-1.96V, so a pin reset should be asserted before VDD drops below 1.96V. The pin-reset should be held low until VDD is >1.98V, which is the maximum power-on reset threshold. The diagrams below demonstrate an example VDD waveform that can cause the regulator initialization to fail.
Figure 1. VDD Decay and Recovery
This figure shows the proper recovery sequence, or what will happen to a working device (not affected by RMU_E102) when VDD falls to 0.9V. Here, the regulator restarts after VDD is restored, and the DECOUPLE voltage returns to 1.8V.
Figure 2. VDD Decay and DECOUPLE failure This figure shows the failure mode for a device affected by RMU_E102 when VDD falls to 0.9V. As you can see the regulator fails to re-initialize properly, and the DECOUPLE voltage continues to fall until reaching 0V. At this point a power-on reset must be performed to recover the device.
As mentioned above, there are two workarounds to the issue.
B. RMU_E102 is an erratum that effects some devices from the following EFM32 Series 0 products:
This erratum does not affect EFM32 Gecko, Giant Gecko, or any EFM32 Series 1 devices.
C. To avoid issues caused by RMU_E102, the following precautions should be taken.
D.
A production screen has been implemented for EFM32 Tiny Gecko that catches devices susceptible to this condition and is implemented on material with date code 1909 and later. Silicon fixes are planned for the remaining devices.
|
Mar 04 2019, 3:30 PM |
![]() |
Updated
CP2114 B02 I2C Command Array Generator on Knowledge Base
Attached to this article is a python 3 script to generate the I2C command arrays for a CP2114-B02 device.
This script interprets the following commands to construct the command byte-array.
In addition to these commands, the command list must begin with one of the following sequence identifiers:
Note - only one sequence can be generated at a time with this script. If all three sequences are needed, they will need to be generated individually, then appended together into one large byte array.
Here is an example image of the script running:
The left panel is the 'input' field, where commands are typed. The right panel is the 'output' field, where the byte array is generated. The byte array is refreshed any time return/enter are pressed in the input field.
The bottom panel is for any errors that may arise.
As an example, this is the input text required to generate a configuration for the CS42L55 codec:
RESET_SEQUENCE setGPIO(0, 4) delay_us(250) delay_us(250) delay_us(250) delay_us(250) setGPIO(1, 4) delay_us(1) write_stop(0x94, [0x00, 0x99]) write_stop(0x94, [0x2E, 0x30]) write_stop(0x94, [0xB2, 0x07, 0xFD, 0xF8, 0xDC, 0xF8, 0x6C]) write_stop(0x94, [0x3A, 0xF8]) write_stop(0x94, [0xBC, 0xD3, 0x23, 0x81, 0x46]) write_stop(0x94, [0x00, 0x00]) write_stop(0x94, [0x03, 0x0A]) write_stop(0x94, [0x84, 0x02, 0x09]) write_stop(0x94, [0x06, 0x20]) write_stop(0x94, [0x2A, 0x00]) write_stop(0x94, [0x9A, 0xC4, 0xC4, 0xC4, 0xC4]) write_stop(0x94, [0x02, 0x08]) delay_ms(75) write_stop(0x94, [0x9A, 0x7A, 0x00, 0x00])
This generates the following binary array:
F9 6E 00 47 04 64 FA 64 FA 64 FA 64 FA 47 84 64 01 57 03 94 00 99 50 57 03 94 2E 30 50 57 08 94 B2 07 FD F8 DC F8 6C 50 57 03 94 3A F8 50 57 06 94 BC D3 23 81 46 50 57 03 94 00 00 50 57 03 94 03 0A 50 57 04 94 84 02 09 50 57 03 94 06 20 50 57 03 94 2A 00 50 57 06 94 9A C4 C4 C4 C4 50 57 03 94 02 08 50 44 4B 57 05 94 9A 7A 00 00 50 00
Syntax errors will be displayed in the bottom panel:
Note, the first version of this script, attached to the article, had bugs that created invalid outputs. The fixed script is attached as cp2114_b02_commandGenerator_FIXED.zip. In this version the escape key is used to evaluate the input and generate the output. |
Feb 27 2019, 4:20 PM |
![]() |
Posted
Error L121: Improper Fixup on Knowledge Base
Question: What causes the L121 Improper Fixup error in Keil C51? How can I fix it? Answer: The most common cause is that, when the code was compiled, the compiler assumed functions were going to be close enough together to use the ACALL instruction, which can only jump 2k from its current destination. However, if the linker places functions farther apart than this, this fixup error occurs. You can resolve this issue by changing the Memory Model setting in the Compiler to Large (program size 64k). |
Dec 20 2018, 10:36 PM |
![]() |
Posted
Maximum capacitive load on GPIO pin on Knowledge Base
Question: What is the largest capacitor value that I can place as a load on a GPIO pin? Answer: The relevant specification to determine the maximum capacitance on a pin is the maximum amount of current that the pin can sink or source. This is typically +/- 100 mA. If you consider an infinite capacitance on a gpio to ground, this effectively creates a short between the pin and ground. In certain drive strength modes, a gpio can tolerate this condition indefinitely, as it would not be able to supply more current than the maximum. For example, on EFM32LG devices, a pin can sink or source 100 mA, but the pin, when in DRIVEMODE = STANDARD, can only source 40 mA before the voltage at the pin is driven to zero (see the output current diagrams in the GPIO section of the datasheet) . So, in a short-to-ground event, the pin would source 40 mA indefinitely. In this case, when DRIVEMODE = STANDARD, or a lower setting, even an infinite capacitor would not violate the GPIO specifications, so any amount of capacitance is acceptable. However, this same device, in DRIVEMODE = HIGH, can potentially source more than 100 mA under a short condition, which would damage the pin. In this case, some method for current limiting should be implemented to prevent damage to the device.
|
Dec 20 2018, 3:55 PM |
![]() |
Posted
Simplicity Studio can not detect or debug MCU Plugin Board for EFM32 Development Kit on Knowledge Base
Problem I have an EFM32 Development Kit with an MCU Plugin Board (e.g. EFM32WG-DK3850). Simplicity Studio detects the Mainboard but not the MCU Plugin Board (including the MCU). How can Simplicity Studio detect the MCU on this board, so I can start a debug session?
Solution For older boards such as MCU Plugin Boards for EFM32 Development Kits, the user must manually specify the target MCU part number in Simplicity Studio before it can connect/debug the MCU. 1. In the Simplicity Studio Launcher, Debug Adapter pane, right click J-Link Silicon Labs > Device Configuration. 2. In the Device Hardware tab, under Boards, add your Plugin Board (e.g. “EFM32 Wonder Gecko DK MCU Plugin Board…”) and the Target Part should auto-populate. Click OK. 3. The Debug Adapters pane should now show the MCU part number. And Simplicity Studio is now setup to debug the board.
|
Dec 19 2018, 8:23 PM |
![]() |
Posted
What does Silicon Labs mean by Not Recommended for New Design (NRND)? on Knowledge Base
Question: What does NRND really mean and what should the take away be if comparable or replacement devices have the same longevity commitment? Answer: NRND typically means that we anticipate or that we've seen a decline in customer sales for a given device and thus it is unlikely that we will continue to produce this device beyond our longevity commitment. Many of our 8-bit devices have the same longevity commitments but are in full production and do not bare the NRND label. This usually indicates that the device continues to be purchased in large quantities by our distributors/customers and as of now, the device is in continuous production to keep up with demand. This does not guarantee production beyond our longevity commitment, as we cannot predict the market through that date, but the larger customer base is a good indicator that we may continue to support this device beyond our initial commitment. For a look at our 8-bit longevity commitment, you can visit this link https://www.silabs.com/products/mcu/8-bit/longevity-commitment. |
Dec 18 2018, 4:55 PM |
![]() |
Posted
How to debug when using Gecko Bootloader on Knowledge Base
Question: How do I debug when using Gecko Bootloader?
Answer: The debug plugin provides the bootloader with support for debugging output. If the plugin is configured to enable debug prints, short debug messages will be printed over Serial Wire Output (SWO), which can be accessed in multiple ways, including using Simplicity Commander, and by connecting to port 4900 of the Wireless Starter Kit TCP/IP interface. Below are the steps to enable debug prints for the gecko bootloader 1. Configure the serial printing option in the Hardware Configurator of the gecko bootloader. Options on setting up the serial printing can be found here - https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2017/12/03/setting_up_serialou-fJAC 2. Turn on the debug option in the utility plugin of the .isc file of the bootloader and enable debug prints option in the plugin. This will enable the debugging in the bootloader.
|
Dec 11 2018, 9:14 AM |
![]() |
Posted
What are the reserved reset-reason codes for custom Gecko Bootloader usage? on Knowledge Base
Question: What are the reserved reset-reason codes for custom Gecko Bootloader usage? Answer: The first word of SRAM is used as shared memory between the bootloader and the application to flag the reason for a reset. The different possible reset reasons are defined in the Reset Information part of the Application Interface, in the file btl_reset_info.h. For custom reset reasons it is recommended to set the high bit in order to be “far away” from Silicon Labs codes, i.e. 0x8000 or higher Note: 0xC33C & 0xF00F reset codes are already used by Silicon Labs. |
Dec 11 2018, 9:12 AM |
![]() |
Posted
Syntax error in Simplicity Studio when declaring interrupts? on Knowledge Base
Question: Why do I receive syntax errors in Simplicity Studio when defining an interrupt? The code compiles and works correctly, but declaring an interrupt, such as this one, gives a syntax error in Studio:
Answer: This occurs since Simplicity Studio uses a generic C syntax parser when looking for syntax errors in code. It doesn't understand compiler-specific C code, like that used by Keil C51 to define an interrupt function - the 'interrupt' keyword and interrupt number after the function declaration aren't standard C, so it throws a syntax error. Keil, however, when the project is compiled, understands this syntax and compiles the code correctly.
|
Dec 03 2018, 6:00 PM |