EFM32 Giant Gecko Series 1

EFM32GG12 Errata

This document contains information on the EFM32GG12 errata. The latest available revision of this device is revision A.

For errata on older revisions, refer to the errata history section for the device. The revision information is typically specified in or near
the trace code on the device. Refer to the package marking information in the data sheet for more information.

Errata effective date: December, 2018.

silabs.com | Building a more connected world. Rev. 0.1

 EFM32GG12 Errata
Active Errata Summary

1. Active Errata Summary

These tables list all known errata for the EFM32GG12 and all unresolved errata in revision A of the EFM32GG12.

Table 1.1. Errata History Overview

Designator Title/Problem Exists on Re-

vision:

ADC_E213 ADC KEEPINSLOWACC Mode X

CSEN_E201 CSEN_DATA in Debug Mode X

CSEN_E202 CSEN Baseline DMA Transfers X

DBG_E204 Debug Recovery with JTAG Does Not Work X

EMU_E217 EM4S Not Supported in 5V Sub-System Powered Devices at Temperatures Above X

85°C

EMU_E218 Entering Backup Mode with RESETn Low X

EMU_E219 5V Regulator Output Affected by DC-DC Mode Changes X

I2C_E206 Slave Holds SCL Low After Losing Arbitration X

MSC_E201 Invalid Data Cached After a Bus Fault X

MSC_E202 SRAM Does Not Support Prefetch When ECC is Enabled X

RMU_E202 External Debug Access Not Available After Watchdog or Lockup Full Reset X

USART_E204 IrDA Modulation and Transmission of PRS Input Data X

silabs.com | Building a more connected world. Rev. 0.1 | 2

 EFM32GG12 Errata
Active Errata Summary

Table 1.2. Active Errata Status Summary

Errata # Designator Title/Problem Workaround Affected Resolution

Exists Revision

1 ADC_E213 ADC KEEPINSLOWACC Mode No A —

2 CSEN_E201 CSEN_DATA in Debug Mode Yes A —

3 CSEN_E202 CSEN Baseline DMA Transfers Yes A —

4 DBG_E204 Debug Recovery with JTAG Does Not Work Yes A —

5 EMU_E217 EM4S Not Supported in 5V Sub-System Powered No A —

Devices at Temperatures Above 85°C

6 EMU_E218 Entering Backup Mode with RESETn Low Yes A —

7 EMU_E219 5V Regulator Output Affected by DC-DC Mode Yes A —

Changes

8 I2C_E206 Slave Holds SCL Low After Losing Arbitration Yes A —

9 MSC_E201 Invalid Data Cached After a Bus Fault Yes A —

10 MSC_E202 SRAM Does Not Support Prefetch When ECC is En- Yes A —
abled

11 RMU_E202 External Debug Access Not Available After Watchdog Yes A —

or Lockup Full Reset

12 USART_E204 IrDA Modulation and Transmission of PRS Input Data Yes A —

silabs.com | Building a more connected world. Rev. 0.1 | 3

 EFM32GG12 Errata
Detailed Errata Descriptions

2. Detailed Errata Descriptions

2.1 ADC_E213 – ADC KEEPINSLOWACC Mode

Description of Errata

When WARMUP-MODE in ADCn_CTRL is set to KEEPINSLOWACC, the ADC does not track the input voltage. Also, the ADC keeps
the input muxes closed even during channel switching, making it not recommended to operate the ADC in KEEPINSLOWACC mode.

Affected Conditions / Impacts

KEEPINSLOWACC warmup mode does not function properly.

Workaround

There is currently no workaround for this issue.

Resolution

There is currently no resolution for this issue.

2.2 CSEN_E201 – CSEN_DATA in Debug Mode

Description of Errata

Reading CSEN_DATA in debug mode inadvertently clears pending CSEN data DMA requests.

Affected Conditions / Impacts

Reads of CSEN_DATA clear pending receive data DMA requests. This would be expected in normal operation as the DMA reads
CSEN_DATA to transfer newly acquired results. These reads are intentional, but any read of CSEN_DATA, including while in debug
mode, has the same effect. Thus, viewing the CSEN module registers in a debugger, such as in Simplicity Studio, can, inadvertently,
clear pending CSEN DMA requests resulting in subsequent data being received out of order and with insertions of random data.

Workaround

Do not use a debugger to read the CSEN registers while DMA is enabled.

Resolution

There is currently no resolution for this issue.

silabs.com | Building a more connected world. Rev. 0.1 | 4

 EFM32GG12 Errata
Detailed Errata Descriptions

2.3 CSEN_E202 – CSEN Baseline DMA Transfers

Description of Errata

DMA transfers to CSEN_DMBASELINE do not occur in the expected order.

Affected Conditions / Impacts

When using delta modulation, a baseline value must be written to CSEN_DMBASELINE before each conversion. However, when
DMA is used to do this, these writes occur after the desired conversion instead of before the conversion as is required. This means
that in a given sequence of conversions serviced by DMA, the write to CSEN_DMBASELINE that should happen before conversion N
is actually written in advance of conversion N + 1, leading to potentially erroneous results.

Workaround

Manually write the first value to CSEN_DMBASELINE and then use the DMA to perform subsequent baseline writes. Thus, in the
case of a sequence consisting of four conversions, the first baseline value would be written to CSEN_DMBASELINE under software
control (e.g. before the conversion trigger occurs). The next three values can be written by the DMA after the first and each subse-
quent conversion occurs.

After the final conversion, which would be the fourth in this example, the DMA will service a final write request to CSEN_DMBASE-
LINE. This final transfer can be (1) a dummy value if no further conversions are required, (2) the initial baseline value in the case
where conversions are repeated in a loop, or (3) the initial baseline value for a new, yet-to-be-triggered series of conversions.

Resolution

There is currently no resolution for this issue.

2.4 DBG_E204 – Debug Recovery with JTAG Does Not Work

Description of Errata

The debug recovery algorithm of holding down pin reset, issuing a System Bus Stall AAP instruction, and releasing the reset pin does
not work when using the JTAG debug interface. When using the JTAG debug interface, the core will continue to execute code as soon
as the reset pin is released.

Affected Conditions / Impacts

The debug recovery sequence will not work when using the JTAG debug interface.

Workaround

Use the Serial Wire debug interface to implement the debug recovery sequence.

Resolution

There is currently no resolution for this issue.

2.5 EMU_E217 — EM4S Not Supported in 5V Sub-System Powered Devices at Temperatures Above 85°C

Description of Errata

When system uses 5V sub-system to power up the EFM chip, energy mode EM4 Shutoff is only supported up to 85C. When a system
that uses the 5V sub-system to power up the EFM chip is in EM4 Shutoff at a temperature above 85C, the output voltage VREGO of
the 5V sub-system will not stay above the required minimum AVDD voltage of 1.62V due to added leakage at high temperatures,
which might be above the maximum 20uA current source capability of the 5V sub-system in EM4 Shutoff.

Affected Conditions / Impacts

Systems using the 5V sub-system and EM4S at high temperatures.

Workaround

There is currently no workaround for this issue. The recommendation for the 5V sub-system powered devices is to use EM4 Hibernate
instead of EM4 Shutoff at temperatures above 85C.

Resolution

There is currently no resolution for this issue.

silabs.com | Building a more connected world. Rev. 0.1 | 5

 EFM32GG12 Errata
Detailed Errata Descriptions

2.6 EMU_E218 — Entering Backup Mode with RESETn Low

Description of Errata

When the device is configured…

• for entry into backup mode when main power is removed or otherwise falls below safe operating levels (EMU_BUCTRL program-
med accordingly),
• with the proper supply present on the BU_VIN pin to provide retention power in backup mode,
• where assertion of RESETn causes a soft reset (the default behavior because Configuration Lock Word 0 bit 2 is 1 on a factory
fresh device shipped with erased flash ), and
• such that the soft reset event causes the EMU to be reset (RMU_CTRL_PINMODE = FULL, which is the default state, or
RMU_CTRL_PINMODE = EXTENDED),

…and the RESETn pin is asserted (goes low), the system enters backup mode even when main power is not removed or does not fall
below the normal operating threshold. The device will not recover from backup mode until a power-on reset occurs.

Affected Conditions / Impacts

Systems making use of backup mode in which the RESETn pin can be asserted by an external device and in which assertion of RE-
SETn causes a soft reset because the default behavior of the pin has not been changed.

Workaround

There are two possible workarounds for this issue:

• Program Configuration Lock Word 0 (CLW0) bit 2 to 0 so that assertion of RESETn always cause a hard reset.
• Change the level of reset caused by assertion of the RESETn pin to LIMITED by writing the appropriate value to the PINMODE
field in the RMU_CTRL register.

Resolution

There is currently no resolution for this issue.

2.7 EMU_E219 — 5V Regulator Output Affected by DC-DC Mode Changes

Description of Errata

When the 5V regulator — which also powers the transceiver on devices with USB — is enabled and regulating (typically to 3.3V), its
output as seen on the VREGO pin can experience momentary fluctuations in response to certain DC-DC converter mode transitions.

For example, in the worst case, a DC-DC transition from BYPASS mode to LOWNOISE mode can cause VREGO to momentarily
overshoot by approximately 550 mV for around 10 ms. Similarly, a DC-DC transition from OFF mode to LOWNOISE mode can cause
VREGO overshoot of approximately 330 mV for around 1 ms. These transient durations correlate directly with the time it takes for
VDCDC to return to 1.8V when the device is connected as recommended in Application Note AN0948: EFM32 and EFR32 Series 1
Power Configurations and DC-DC.

In both cases, after the momentary overshoot, the VREGO output will recover to a DC level approximately 30 mV higher than it was
when the DC-DC converter was in the BYPASS or OFF modes.

Affected Conditions / Impacts

USB communications could be interrupted in systems where both the 5V regulator and DC-DC converter are used, and the DC-DC
mode is changed. The overshoot and subsequent settling of VREGO above its nominal output level after a DC-DC mode change may
present concerns if VREGO powers AVDD, IOVDD, or other components in the system.

Workaround

Because VREGO supplies the USB transceiver, DC-DC mode transitions from BYPASS to LOWNOISE or OFF to LOWNOISE should
not be performed while USB communications activity is ongoing in order to avoid the risk of generating a bit error.

If VREGO is used to supply AVDD, IOVDD, or other components in the system, care should be taken to ensure that circuits in these
power domains are tolerant of the kinds of supply perturbations described above and/or to limit DC-DC mode transitions to periods
when the system can tolerate such supply perturbations.

Resolution

There is currently no resolution for this issue.

silabs.com | Building a more connected world. Rev. 0.1 | 6

 EFM32GG12 Errata
Detailed Errata Descriptions

2.8 I2C_E206 – Slave Holds SCL Low After Losing Arbitration

Description of Errata

If, while transmitting data as a slave, arbitration is lost, SCL is unintentionally held low for an indefinite period of time.

Affected Conditions / Impacts

The winner of arbitration cannot use the bus because SCL is never released.

Workaround

If the I2C arbitration lost flag is asserted (I2C_IF_ARBLOST = 1) in slave mode (I2C_STATE_MASTER = 0), application software
needs to wait for at least one SCL high time and then issue the transmission abort command (set I2C_CMD_ABORT = 1), thus releas-
ing SCL.

Resolution

There is currently no resolution for this issue.

2.9 MSC_E201 – Invalid Data Cached After a Bus Fault

Description of Errata

The instruction cache is not flushed in the event of a bus fault. As a result, when an instruction fetch results in a bus fault, invalid data
may be cached. When invalid data is cached due to a bus fault, the next time the instruction that caused the bus fault is fetched, the
processor core will get the invalid cached data without any bus fault.

Affected Conditions / Impacts

This problem manifests itself in software that implements a bus fault handler because the processing of the bus fault does not invalid-
ate the instruction cache.

Workaround

Set MSC->CACHECMD.INVCACHE=1 upon entering the bus fault handler to invalidate the instruction cache.

Resolution

There is currently no resolution for this issue.

2.10 MSC_E202 – SRAM Does Not Support Prefetch When ECC is Enabled

Description of Errata

Prefetch cannot be used when the corresponding SRAM has ECC enabled.

Affected Conditions / Impacts

Erroneous write-back operations can lead to further corruption when 1-bit ECC errors occur. The optional bus fault upon 2-bit errors
(MSC->CTRL.RAMECCERRFAULTEN=1) can cause the SRAM to generate invalid bus protocol responses, leading to unpredictable bus
master (e.g. CPU or LDMA) behavior.

Workaround

Because this erratum was discovered on the pin-compatible predecessor, EFM32GG11, a preventive measure was implemented on
EFM32GG12. When both ECC and prefetch are enabled, the automatic hardware write back feature that corrects 1-bit ECC errors is
disabled. This permits both ECC and prefetch to remain enabled, as well as the optional generation of bus faults upon 2-bit errors, but
requires software to perform the necessary write back operations to correct words in which 1-bit ECC errors are detected
(MSC_IF_RAM1ERR1B or MSC_IF_RAMERR1B is set).

Resolution

There is currently no resolution for this issue.

silabs.com | Building a more connected world. Rev. 0.1 | 7

 EFM32GG12 Errata
Detailed Errata Descriptions

2.11 RMU_E202 – External Debug Access Not Available After Watchdog or Lockup Full Reset

Description of Errata

When a reset is triggered in full-reset mode, a debugger will not be able to read AHB-AP or ARM core registers.

Affected Conditions / Impacts

Systems using the full reset mode for watchdog or lockup resets will see limited debugging capability after one of these resets trig-
gers.

Workaround

There are three possible workarounds:

• Software should configure peripherals to either LIMITED or EXTENDED mode if full debugger functionality is needed after a watch-
dog or lockup reset.
• When using FULL reset mode, appending at least 9 idle clock cycles to the last debug command will allow the transaction to com-
plete.
• A power cycle or hard pin reset will restore normal operation.

Resolution

There is currently no resolution for this issue.

2.12 USART_E204 — IrDA Modulation and Transmission of PRS Input Data

Description of Errata

If the USART IrDA modulator is configured to accept input from a PRS channel, the incoming data stream will not be transmitted be-
cause the required clock from the baud rate generator is never enabled.

Affected Conditions / Impacts

It is not possible for the USART IrDA modulator to directly transmit data from a source other than the USART's own transmitter. The
USART_IRCTRL_IRPRSEN bit should remain at its reset state of 0.

Workaround

Assuming the data to be sent via the PRS is also data that could be received by the EFM32/EFR32 USART, then the data can be
received using the USART's PRS RX feature (USART_INPUT_RXPRS = 1), stored in RAM (e.g. using DMA), and then transmitted
with IrDA mode enabled. In cases where IrDA operation is transmit-only, the PRS RX data can be received on the same USART do-
ing the transmission. If IrDA operation is bidirectional, then another USART must be used to receive the PRS data.

If the data to be sent is in some other format (e.g. pulses from a timer output), then there is no direct way to transmit it using the IrDA
modulator. It would be necessary to capture the data in some other way and reformat it as serial data timed according to the clock
generated by the USART.

Resolution

There is currently no resolution for this issue.

silabs.com | Building a more connected world. Rev. 0.1 | 8

 EFM32GG12 Errata
Errata History

3. Errata History

This section contains the errata history for EFM32GG12 devices.

For errata on latest revision, refer to the beginning of this document. The device data sheet explains how to identify chip revision, either
from package marking or electronically.

3.1 Errata History Summary

This table lists all resolved errata for the EFM32GG12.

Table 3.1. Errata History Status Summary

Errata # Designator Title/Problem Workaround Affected Resolution

Exists Revision

There are no errata in the errata history for this device.

silabs.com | Building a more connected world. Rev. 0.1 | 9

 EFM32GG12 Errata
Revision History

4. Revision History

Revision 0.1

December, 2018

• Initial release.

silabs.com | Building a more connected world. Rev. 0.1 | 10

 Simplicity Studio
One-click access to MCU and
wireless tools, documentation,
software, source code libraries &
more. Available for Windows,
Mac and Linux!

IoT Portfolio SW/HW Quality Support and Community

www.silabs.com/IoT www.silabs.com/simplicity www.silabs.com/quality community.silabs.com

Disclaimer
Silicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or
intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical"
parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes
without further notice and limitation to product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included
information. Silicon Labs shall have no liability for the consequences of use of the information supplied herein. This document does not imply or express copyright licenses granted
hereunder to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any Life Support System without the specific written consent of
Silicon Labs. A "Life Support System" is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal
injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass
destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons.

Trademark Information
Silicon Laboratories Inc.® , Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®,
EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®,
Gecko®, ISOmodem®, Micrium, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress®, Zentri, Z-Wave, and others are trademarks or
registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM
Limited. All other products or brand names mentioned herein are trademarks of their respective holders.

Silicon Laboratories Inc.

400 West Cesar Chavez
Austin, TX 78701
USA

http://www.silabs.com