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

www.silabs.com/32bit-errata

Affected Devices

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

• EFM32HG, all revisions affected (most recent is B), fixed devices are revision B date code 1751
• EFM32LGE, revision *E affected, fixed devices are revision E date code 1742
• EFM32WG, revision A affected, fixed devices are revision A date code 1742
• EFM32ZG, revision A affected, fixed devices are revision A date code 1742
• EZR32WG, all revisions affected (most recent is B), fixed devices are revision B date code 1742
• EZR32LG, all revisions affected (most recent is B), fixed devices are revision B date code 1742
• EZR32HG, all revisions affected (most recent is B), fixed devices are revision B date code 1751

* Rev D and earlier do not have the issue

Additional Notes Regarding the Failure Mode

When exiting EM2 or EM3, some devices may intermittently execute code incorrectly or enter the hard fault handler instead of entering the expected ISR associated with the wake source.

The flash is powered down in EM2 and EM3 to save power. Some control registers in the flash can rarely enter an invalid state upon power-on, causing the first read of flash to be incorrect. If this occurs after exiting EM2 or EM3, the core attempts to fetch the interrupt address, but the value will be incorrect and may be invalid. In the case of an invalid value, the core will then jump to the hard fault handler for attempting to execute code from an invalid address. All subsequent reads from the flash are unaffected, and it is only the first flash read after exit from EM2 or EM3 that is potentially erroneous.

Software Workaround Installation

The attached ZIP file contains software workarounds for each affected device family for the GCC build tools. These workarounds implement the fix for EM2, but the code and methodology is similar for applications using EM3.

How the Firmware Workaround Works

The firmware workaround relocates the full interrupt vector table to RAM in addition to the peripheral ISRs that are used for EM2 wake-up.  When waking from EM2, the core will then jump to the ISR in RAM that performs a dummy read of the flash to clear the potential flash read issue. This method consumes 224 bytes of RAM for Leopard Gecko devices.

Note that when using this workaround to address this issue, the system designer must ensure that no interrupts without the dummy read of flash will wake the device out of EM2 and start executing. To be safe, ensure the interrupts that include the dummy read of flash are the highest interrupt priority prior to entering EM2.

Additional implementation details can be found in the comments supplied in the workaround source code.

For any questions on this issue or the workaround, contact technical support.

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

www.silabs.com/32bit-errata

Affected Devices

The following list shows devices that will exhibit the failure mode. 

• EFM32HG, all revisions affected (most recent is B), fixed on revision B devices with PROD_REV greater than or equal to 0x8E and date code greater than or equal to 1751
• EZR32HG, all revisions affected (most recent is B), fixed on revision B devices with PROD_REV greater than or equal to 0x86 and date code greater than or equal to 1751

Additional Notes Regarding the Failure Mode

Versions of the production bootloader prior to v2.06 require a crystal. Version 2.06 of the bootloader has been updated to no longer require a crystal, since one is not needed on these products.

Systems intending to use the production bootloader that do not include a crystal will not be able to run the bootloader on affected devices.

For systems intending to use the production bootloader on affected devices, add a temporary crystal to the design that can later be removed when it's no longer needed.

This issue will be resolved in future devices, but the date code of the fixed devices is not yet available.

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

www.silabs.com/32bit-errata

Affected Devices

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

• EFM32HG, all revisions affected (most recent is B), fixed devices are revision B date code 1751
• EFM32LGE, revision *E affected, fixed devices are revision B date code 1742
• EFM32WG, revision A affected, fixed devices are revision A date code 1742
• EFM32ZG, revision A affected, fixed devices are revision A date code 1742
• EZR32WG, all revisions affected (most recent is B), fixed devices are revision B date code 1742
• EZR32LG, all revisions affected (most recent is B), fixed devices are revision B date code 1742
• EZR32HG, all revisions affected (most recent is B), fixed devices are revision B date code 1751

* Rev D and earlier do not have the issue

Additional Notes Regarding the Failure Mode

When exiting EM2 or EM3, some devices may intermittently execute code incorrectly or enter the hard fault handler instead of entering the expected ISR associated with the wake source.

The flash is powered down in EM2 and EM3 to save power. Some control registers in the flash can rarely enter an invalid state upon power-on, causing the first read of flash to be incorrect. If this occurs after exiting EM2 or EM3, the core attempts to fetch the interrupt address, but the value will be incorrect and may be invalid. In the case of an invalid value, the core will then jump to the hard fault handler for attempting to execute code from an invalid address. All subsequent reads from the flash are unaffected, and it is only the first flash read after exit from EM2 or EM3 that is potentially erroneous.

Software Workaround Installation

The attached ZIP file contains software workarounds for each affected device family for the GCC build tools. These workarounds implement the fix for EM2, but the code and methodology is similar for applications using EM3.

How the Firmware Workaround Works

The firmware workaround relocates the full interrupt vector table to RAM in addition to the peripheral ISRs that are used for EM2 wake-up.  When waking from EM2, the core will then jump to the ISR in RAM that performs a dummy read of the flash to clear the potential flash read issue. This method consumes 224 bytes of RAM for Leopard Gecko devices.

Note that when using this workaround to address this issue, the system designer must ensure that no interrupts without the dummy read of flash will wake the device out of EM2 and start executing. To be safe, ensure the interrupts that include the dummy read of flash are the highest interrupt priority prior to entering EM2.

Additional implementation details can be found in the comments supplied in the workaround source code.

For any questions on this issue or the workaround, contact technical support.