Tags
- Wireless
- SiM3C1xx
- Security
- EFR32FG1V132F256GM32
- EFR32FG1V132F128GM48
- EZR32WG
- Errata
- USBXPress Kits
- EFM32PG1B100F128GM32
- EFR32FG1V132F64GM32
- Blue Gecko Bluetooth Low Energy SoCs
- EFR32BG1V132F256GM32
- EFM32ZG-STK3200
- Wonder Gecko
- EFR32FG1V132F128GM32
- Knowledge Base Articles
- EFM32G-DK3550
- SiM3U1xx
- EFM32GG11B820F2048GL192
- Pearl Gecko
- Simplicity Studio
- Tiny Gecko
- Mighty Gecko SoCs
- EFR32MG1V132F256GM48
- Precision32 Development Suite
- Blue Gecko Bluetooth Low Energy Modules
- Compilers
- DC-DC Converters
- EFR32BG1V132F128GM32
- RF Hardware
- Tiny Gecko S1
- Giant Gecko
- EFR32MG1V132F256GM32
- EFM32GG-DK3750
- IAR Embedded Workbench IDE
- 32-bit MCUs
- Gecko
- 32-bit MCU SDK
- Leopard Gecko
- Gecko SDK
- EFR32FG1V132F64GM48
- Bluetooth SDK
- SiM3L1xx
- EZR32HG
- Jade Gecko
- Giant Gecko S1
- EZR32LG
- Flex Gecko
- 8-bit MCUs
- Zero Gecko
- EFR32FG1V132F256GM48
- Happy Gecko
- EFM32WG-DK3850
- EFR32BG1V132F256GM48
- EFM32LG-DK3650
- 32-bit MCU Kits
- EFR32BG1V132F128GM48
- Interface
Top Authors
Archives
- 2016 April
- 2016 May
- 2016 June
- 2016 July
- 2016 August
- 2016 September
- 2016 October
- 2016 November
- 2016 December
- 2017 January
- 2017 February
- 2017 March
- 2017 April
- 2017 May
- 2017 June
- 2017 July
- 2017 August
- 2017 September
- 2017 October
- 2017 November
- 2017 December
- 2018 January
- 2018 February
- 2018 March
- 2018 April
- 2018 May
- 2018 June
- 2018 July
- 2018 August
- 2018 September
- 2018 October
- 2018 November
- 2018 December
- 2019 January
- 2019 February
- 2019 March
- 2019 April
- 2019 May
- 2019 June
- 2019 November
- 2020 January
- 2020 March
- 2020 April
- 2020 May
- 2020 June
- 2020 October
- 2020 December
- 2021 February
- 2021 March
EMU_E110 - Potential Hard Fault when Exiting EM2 or EM3
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.
* 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.
Hello Tabitha:
We are now struggling to solve this issue in product.
Could you explain more information about this issue:
Flash_Address = ptrFlashVectorTable[VTABLE_EM2_ISR_OFFSET];
Flash_Address = ptrFlashVectorTable[__get_IPSR()];
Why should we need to read flash data about IRQ Vector in first case? And then get the same address with another method? How do the program be error to read flash?
We have patched the code but issue is still happen rarely, how could we check our is all well? Or, is there some methold to increase the error case?
Thank you very much
Alex
Why should we need to read flash data about IRQ Vector in first case?
As the "Additional Notes Regarding the Failure Mode" section explained, this is a dummy flash reading, you could read other flash address. In fact we don't care the readback value.
And then get the same address with another method?
Since the flash read error only happen for the 1st flash reading after exit from EM2/EM3, this second time read should get correct value stored in the flash.
How do the program be error to read flash?
I am not sure I understand your question correctly or not. As far as I know the first flash read after exit EM2/EM3 sometimes fail. the 1st read maybe return a invalid value (for example 0xFFFFFFFF) and cause hard fault.
We have patched the code but issue is still happen rarely, how could we check our is all well? Or, is there some methold to increase the error case?
Be sure you patch it correctly. You could double check if the code really run in RAM (for keil project you may need to change the linker file). We also have a good KBA to debug hardfault issue as below:
https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2017/05/09/emu_e110_-_potential-i2Pn
Does this issue also affect EFM32TG?
I don't think so. all the MCU would be affected was listed in the table. If the part was not listed here, I don't think it would be affected.
The latest emlib has implemented a different FW workaround.
You could get the workaround in file em_emu.c/h
Just got EZR32LG230 with date code 1807.
Is this version include the HW fix for this errata?
Where can I find updated errata file (latest in SiLab site is from April 10th, 2017)
Thx
1. Is there documentation on the "different FW workaround" in em_emu.c? It appears to me to work around the problem by executing the WFI instruction from RAM, and then having the subsequent instruction read and discard data from Flash, before returning execution to flash. However, it would seem that if execution of the ISR occurred before the code returned from the WFI, this wouldn't be sufficient?
2. Is the PROD_REV register distinct between the faulty EFM32LG Rev E devices and the non-faulty devices?