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.
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
0
Does this issue also affect EFM32TG?
0
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:
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.
0
The latest emlib has implemented a different FW workaround.
You could get the workaround in file em_emu.c/h
0
Are EFM32ZG devices with date code 1742 available in local Dist now?
0
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
0
@daganp, how about the revision number your EZR32LG230?
0
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?
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?