See the Errata sheet for your device to see the complete description of this errata and affected products:


Affected Devices


The following table shows devices that might exhibit the failure mode. 


Device Family Device Revision Fixed Revision
EFR32MG12 A, B C, targeted 2017
EFR32FG12 A, B C, targeted 2017
EFR32BG12 A, B C, targeted 2017
EFM32PG12 A, B C, targeted 2017
EFM32JG12 A, B C, targeted 2017
EFR32MG13 B C, targeted 2017
EFR32FG13 B C, targeted 2017
EFR32BG13 B C, targeted 2017


Failure Mode


The device may not properly start during power-on or restart when a voltage droop (brown out) occurs on AVDD. The failure is intermittent.


For power-on, the failure rate tends to increase with slower ramp up rates of AVDD up to 1.8 V and when there are discontinuities in the ramp. The following figure demonstrates an example problematic waveform for this scenario.




For brown out scenarios, the failure rate tends to increase with slower ramp down rates of AVDD down to the brown out (BOD) trip point. The following figure demonstrates an example problematic waveform for this scenario.




To detect this failure state, place a GPIO toggle at the beginning of main() in the device firmware. When this failure occurs, the pin will not be toggling as expected, as the device is not executing any code.


Hardware Workaround


This issue can be resolved with a hardware workaround where an external circuit holds the reset pin low during power-on or brown out until AVDD reaches 1.8 V. For brown out, the reset pin can be configured to hard reset mode as part of the firmware image programmed to the device.


Alternatively, the reset pin must be configured in hard reset mode using the following code:

// Clears the CLW0 bit to enable Hard reset
void enable_hardreset()
  uint32_t value;
  uint32_t newvalue;
  value = *(uint32_t *)0xFE041E8;
  newvalue = value & ~(1 << 2);
  MSC_WriteWord((uint32_t *)0xFE041E8, &newvalue, 4); 


Software Workaround Installation


There is currently no software workaround for all potential failure mechanisms. The software workaround attached will prevent failure in some scenarios, including brown out where AVDD does not drop below ~1.2 V.


The section below describes the software workaround in more detail.


How the Software Workaround Works


A software workaround can be used to eliminate this behavior in cases where the device browns out and AVDD does not drop below ~1.2 V. This workaround places the device in EM4H using VMON as an interrupt source, triggering at a level greater than the BOD threshold (1.8 V). The device will exit EM4H when the voltage either rises above the programmed threshold or resets due to the AVDD voltage decreasing below the EM4 BOD threshold.


If exiting EM4H from a lowered threshold, the device can still enter the erroneous state if it power cycles up, down, and back up again in a time frame that is faster than software can implement the workaround, which is on the order of 1 ms.


The software workaround consists of the following two functions and EMU IRQ handler:



// EM4H setup
void setupEM4H(void)
  EMU_EM4Init_TypeDef init = EMU_EM4INIT_DEFAULT;

  // EM4H with no oscillator or GPIO retention
  init.em4State = emuEM4Hibernate;

// VMON setup
void setupVmon(void)
  EMU_VmonHystInit_TypeDef vmon_hys = EMU_VMONHYSTINIT_DEFAULT; = emuVmonChannel_AVDD;
  vmon_hys.fallWakeup = false;
  vmon_hys.riseWakeup = true;
  vmon_hys.riseThreshold = 2750;  // 2.75 V – customize as needed
  vmon_hys.fallThreshold = 2750;  // 2.75 V – customize as needed


  // Clear pending EMU interrupts

  // Enable EMU NVIC source

  // Enable EMU VMON AVDD falling interrupt

// EMU IRQ handler
void EMU_IRQHandler(void)
  // Clear AVDD falling VMON interrupt

  // Enter EM4 until AVDD comes back


Somewhere in main(), add the following:




// Wait for VMON to go ready
while (!EMU_VmonStatusGet());


These setup functions may need to be customized to incorporate particular configuration options unique to the application.  Furthermore, the EMU IRQ handler may require modification to meet any specific specific application requirements.


Additionally, if using the LFXO or LFRCO, it will be necessary to include code to detect if reset was due to EM4 wake-up and to unlatch registers that are retained upon EM4 entry. For example:



if (RMU_ResetCauseGet() & RMU_RSTCAUSE_EM4RST)


Finally, if the application cannot tolerate the return of the GPIO pins to their reset state upon EM4 entry, it will be necessary to enable GPIO retention in setupEM4H() by adding the following line:



init.pinRetentionMode = emuPinRetentionLatch;


This will then also require some additional steps:


  1. Modify the EMU IRQ handler to place any pins that will remain active in a known state.
  2. Re-enable the GPIO clock and restore all GPIO pins that will be active to their known or otherwise desired states before calling EMU_UnlatchPinRetention(). This may require reading the GPIO_Px_DOUT registers to recover the states of previously configured GPIO pins and issuance of multiple calls to GPIO_PinModeSet() to restore these states.  Failure to call EMU_UnlatchPinRetention() will result in no GPIO pins on the device assuming any configured states or otherwise functioning with assigned peripherals.  Failure to restore retained GPIO pins to their previous states may cause any connected devices to operate improperly or otherwise incorrectly receive or transmit data.

  • Knowledge Base Articles
  • 32-bit MCUs
  • What is the minimum time for holding the reset pin LOW, to force a device reset?
    I could not find this information in datasheet / reference manual.