silabs EFR32 Wireless Gecko User Manual

silabs EFR32 Wireless Gecko

This document contains information on the EFR32FG13 errata. The latest available revision of this device is revision D. Errata that have been resolved remains documented and can be referenced for previous revisions of this device. The device data sheet explains how to identify the chip revision, either from package marking or electronically. Errata effective date: September 2020.

Errata Summary

The table below lists all known errata for the EFR32FG13 and all unresolved errata in revision D of the EFR32FG13.

Errata Overview

Designator| Title/Problem| Workaround

Exists

| Exists on Revision:
---|---|---|---
A| B| C| D
ADC_E213| ADC KEEPINSLOWACC Mode| No| X| X| X| X
ADC_E222| ADC EM2 Wakeup on a Comparator Match Disables EM2 Entry| Yes| X| —| —| —
ADC_E224| ADC Warm-Up Ready Can Cause IDAC, ACMP, or CSEN to Not Function| Yes| X| X| —| —
ADC_E225| Using the ADC in High-Accuracy Bias Mode Will Force All Analog Peripherals to High-Accuracy Bias Mode| No| X| X| —| —
ADC_E228| Limited ADC Sampling Frequency in EM2| No| X| X| X| X
CSEN_E201| CSEN_DATA in Debug Mode| Yes| X| X| X| X
CSEN_E202| CSEN Baseline DMA Transfers| Yes| X| X| X| X
CUR_E203| Occasional Extra EM0/1 Current| No| X| X| X| X
DBG_E203| CRC Debug Command Available| No| X| —| —| —
DBG_E204| Debug Recovery with JTAG Does Not Work| Yes| X| X| X| X
EMU_E211| Radio Clocks Remain Disabled After Voltage Scaling| Yes| X| —| —| —
EMU_E214| Device Erase Cannot Occur if Voltage Scaling Level is Too Low| Yes| X| X| X| X
EMU_E220| DECBOD Reset During Voltage Scaling After EM2 or EM3 Wakeup| Yes| X| X| X| X
I2C_E202| Race Condition Between Start Detection and Timeout| Yes| X| X| X| X
I2C_E203| I2C Received Data Can be Shifted| Yes| X| X| X| X
I2C_E204| I2C0 Does Not Meet Fast Mode Plus (Fm+) Timing at Voltage Scale Level 0| No| X| X| X| X
I2C_E205| Go Idle Bus Idle Timeout Does Not Bring Device to Idle State| Yes| X| X| X| X
I2C_E206| Slave Holds SCL Low After Losing Arbitration| Yes| X| X| X| X
I2C_E207| I2C Fails to Indicate New Incoming Data| Yes| X| X| X| X
LES_E201| LFPRESC Can Extend Channel Start-Up Delay| Yes| X| X| X| X
RMU_E202| External Debug Access Not Available After Watchdog or Lockup Full Reset| Yes| X| X| X| X
RMU_E203| AVDD Ramp Issue| Yes| X| X| —| —
RTCC_E203| Potential Stability Issue with RTCC Registers| Yes| X| X| X| X
RTCC_E205| Wrap Event Can Be Missed| Yes| X| X| X| X
TIMER_E202| Continuous Overflow and Underflow Interrupts in Quad- rature Counting Mode| Yes| X| X| X| X
TRNG_E202| Standards Non-compliance| Yes| X| X| X| —
Designator| Title/Problem| Workaround

Exists

| Exists on Revision:
---|---|---|---
A| B| C| D
USART_E203| DMA Can Miss USART Receive Data in Synchronous Mode| Yes| X| X| X| —
USART_E204| IrDA Modulation and Transmission of PRS Input Data| Yes| X| X| X| X
USART_E205| Possible Data Transmission on Wrong Edge in Syn- chronous Mode| Yes| X| X| X| X
USART_E206| Additional SCLK Pulses Can Be Generated in USART Synchronous Mode| Yes| X| X| X| X
WDOG_E201| Clear Command is Lost Upon EM2 Entry| Yes| X| X| X| X
WTIMER_E201| Continuous Overflow and Underflow Interrupts in Quad- rature Counting Mode| Yes| X| X| X| X

Current Errata Descriptions

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.

ADC_E228 – Limited ADC Sampling Frequency in EM2

Description of Errata

ADC FIFO overflows occur at frequencies that are much lower than the ADC’s maximum theoretical sampling rate.
Affected Conditions / Impacts
ADC sampling frequency is reduced in EM2.
Workaround
There is currently no workaround for this issue.
Resolution
There is currently no resolution for this issue.

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 reader 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.

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. Therefore, 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 subsequent 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.

CUR_E203 – Occasional Extra EM0/1 Current

Description of Errata

Occasionally, when exiting EM2, a low voltage oscillator sometimes continues to run and causes the device to draw an extra ~10 µA when in EM0 or EM1. This oscillator automatically resets when entering EM2 or EM3, so the extra current draw is not present in these modes.
Affected Conditions / Impacts
Systems using EM2 may occasionally see an extra ~10 µA of a current draw in EM0 or EM1.
Workaround
There is currently no workaround for this issue.
Resolution
There is currently no resolution for this issue.

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.

EMU_E214 – Device Erase Cannot Occur if Voltage Scaling Level is Too Low

Description of Errata

The device erases logic and does not check the Voltage Scale Level prior to attempting a device erase. If using Voltage Scale Level 0

(1 V), the device may not be able to erase the flash. This results in a potentially unlockable device if operating at Voltage Scale Level 0 (1 V).

Affected Conditions / Impacts
It is possible that the flash is only partially erased when performing the operation at Voltage Scale Level 0 (1 V). If this results in the debug lock bit not clearing, a locked part doesn’t unlock after the partial erasure (which it is intended to do), and the part remains locked. If subsequent erasures continue to fail, the part would remain locked.
Workaround
The voltage should be set to Voltage Scale Level 2 (1.2 V) before executing the device erase.

For systems that don’t lock the debug interface, the user can follow the debug recovery procedure to halt the CPU before it has a chance to execute code in software to avoid the code scaling the voltage. The device erases can then be executed at Voltage Scale Level 2 (1.2 V) (the power-on default voltage of the device).

For systems that do lock the debug interface, firmware can implement a mechanism whereby it can voltage scale or unlock debug access if its defined authentication method is passed.

Resolution
There is currently no resolution for this issue.

EMU_E220 – DECBOD Reset During Voltage Scaling After EM2 or EM3 Wakeup

Description of Errata

An infrequent, asynchronous, and unrelated internal event can intermittently delay normal BOD state-machine transition sequencing during voltage scaling from VSCALE0 (1.0 Vdc) to VSCALE2 (1.2 Vdc) when emerging from EM2/EM3 to EM0. This delay can cause erroneous DECBOD resets on some devices.
Affected Conditions / Impacts
Systems operating with core voltage scaling can experience a decouple voltage brownout reset (DECBOD) when exiting EM2 or EM3.
Workaround
Systems that use core voltage scaling need to enter EM2 or EM3 via a RAM executed and wait for interrupt instruction with interrupts disabled. Additionally, the EMU writes shown below should be added around EM2/EM3 entry and exit and after voltage scaling completes. This prevents the BOD state- machine transition signals from being delayed. This workaround adds 2.7 µs to the voltage scaling operation.

Note: This workaround is included in em_emu.c in the v2.7.4.0 or later of the Gecko SDK. It is recommended to workaround this issue by using the latest Gecko SDK version.

// Execute from RAM with interrupts disabled

(uint32_t ) (EMU_BASE + 0x1A4) |= 0x1f << 10;

__ WFI();

(uint32_t ) (EMU_BASE + 0x14C) |= 0x01 << 31;

// Enable Interrupts and return to flash execution

. . . .

// After voltage scaling is complete

(uint32_t ) (EMU_BASE + 0x14C) &= ~(0x01 << 31); EMU->IFC = 0xFFFFFFFF;

|
Resolution
There is currently no resolution for this issue.

I2C_E202 – Race Condition Between Start Detection and Timeout

Description of Errata

There is a race condition where the Bus Idle Timeout counter may clear the busy status of the I2C bus after a start condition.
Affected Conditions / Impacts
Software may attempt another I2C start if it thinks the bus is idle. This may disrupt the I2C bus. After the Bus Idle Timeout feature has triggered, it will not detect another idle condition.
Workaround
The software can wait for any of the following conditions before starting an I2C transaction:

• The received address match interrupt indicates that the I2C bus is busy. Software should serve this transaction and proceed accordingly. The software can ignore the wrong busy status.
• The SSTOPIF interrupt flag indicates that the I2C bus has returned to an idle state.
• A defined, system-dependent amount of time to wait after bus activity to ensure that the bus is in an idle state.

Resolution
There is currently no resolution for this issue.

I2C_E203 – I2C Received Data Can be Shifted

Description of Errata

If SDA falls between detection of the start condition and the first rising edge of SCL, the I2C state machine clears the start condition that was just detected, causing the state machine counter to count the rising edge of SCL earlier than it was detected. This causes the received data to be out of sync and the acknowledge phase to occur one SCL clock cycle earlier than expected, thus corrupting the integrity of the I2C bus.

There are two ways in which the falling condition on SDA can potentially happen:

•   In multi-master systems, one master initiates a start condition and then drives SDA high shortly before another master drives SDA low to indicate a start condition.

•   In a single master system, if SDA is high from the last bit of the previous transaction, the master initiates a start condition and then drives SDA low because the MSB of the new address is low.

Affected Conditions / Impacts
I2C operation in slave mode or multi-master mode.
Workaround
This depends on whether the system is multi- or single-master. There is no workaround for multi-master cases. In a single-master system, the state of SDA may not change unless a new address is being sent, such that the falling condition on SDA would not be observed. Whether or not this is the case is dependent on the implementation of the particular I2C master.
Resolution
There is currently no resolution for this issue.

I2C_E204 – I2C0 Does Not Meet Fast Mode Plus (Fm+) Timing at Voltage Scale Level 0

Description of Errata

I2C0 cannot meet Fast Mode Plus (Fm+) timing specifications when the device is operating at Voltage Scale Level 0 (EMU_STATUS_VSCALE = VSCALE0). Attempting to do so can result in false NACK/START/STOP conditions during communication.
Affected Conditions / Impacts
I2C0 is unable to support Fm+ timing at Voltage Scale Level 0 (EMU_STATUS_VSCALE = VSCALE0).
Workaround
There is no workaround for I2C0, and this erratum affects only I2C0 on a given device.
Resolution
There is currently no resolution for this issue.

I2C_E205 – Go Idle Bus Idle Timeout Does Not Bring Device to Idle State

Description of Errata

When the I2C is operating as a slave, if the bus idle timeout is active (I2Cn_CTRL_BITO != 0) and the go idle on bus timeout feature is enabled (I2Cn_CTRL_GIBITO = 1), the bus idle interrupt flag (I2Cn_IF_BITO) sets upon timeout, but the receiver does not enter the idle state.
Affected Conditions / Impacts
The I2C receiver needs to detect a START condition to recover from the bus idle timeout state. If there is another, undefined activity on the bus after the timeout, the receiver will not recover as expected.
Workaround
The I2Cn_CTRL_EN bit can be toggled from 1 to 0 and back to 1 again to resume normal operation. Alternatively, a START condition issued by any other master on the bus (including the EFM32/EFR32 device) will reset the receiver and return it to normal operation.
R esolution
There is currently no resolution for this issue.

**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 the 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 releasing SCL.
Resolution
There is currently no resolution for this issue.

I2C_E207 – I 2 C Fails to Indicate New Incoming Data

Description of Errata

A race condition exists in which the I2C fails to indicate reception of new data when both user software attempts to read data from and the I2C hardware attempts to write data to the I2C_RXFIFO in the same cycle.
Affected Conditions / Impacts
When this race condition occurs, the RX FIFO enters an invalid state in which both I2C_STATUS_RXDATAV = 0 and I2C_STA- TUS_RXFULL = 1. This causes the I2C to discard new incoming data bytes because RX FULL = 1 and would otherwise prevent user software from reading the last byte written by the I2C hardware to RXFIFO because RXDATAV = 0.
Workaround
The user software can recognize and clear this invalid RXDATAV = 0 and RX FULL = 1 condition by performing a dummy read of the RX FIFO (I2C_RXDATA). This restores the expected RXDATAV = 1 and RX FULL = 0 condition. The data from this read can be discarded, and user software can now read the last byte written by the I2C hardware to the RX FIFO (the byte which caused the invalid RXDATAV = 0 and RX FULL = 1 condition).

No data will be lost as long as user software completes this recovery procedure (performing the dummy read and then reading the remaining valid byte in the RX FIFO) before the I2C hardware receives the next incoming data byte.

Resolution
There is currently no resolution for this issue.

LES_E201 — LFPRESC Can Extend Channel Start-Up Delay

Description of Errata

Setting LESENSE_TIMCTRL_LFPRESC to a value other than DIV1 may delay channel start-up longer than the number of LFACLKLESENSE clock cycles specified by LESENSE_TIMCTRL_STARTDLY.
Affected Conditions / Impacts
Delaying channel start-up delays the subsequent excitation and measurement phases and may have an impact on the data returned by the LICENSE.
Workaround
If a channel start-up delay is used (LESENSE_TIMCTRL_STARTDLY > 0), LESENSE_TIMCTRL_LFPRESC must be set to DIV1.
Resolution
There is currently no resolution for this issue.

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 complete.

•   A power cycle or hard pin reset will restore normal operation.

Resolution
There is currently no resolution for this issue.

RTCC_E203 – Potential Stability Issue with RTCC Registers

Description of Errata

RTCC_LOCK and RTCC_POWERDOWN have the potential to be momentarily unstable under some PCLK, Low Energy Peripheral Clock, and APB write scenarios. This stability issue resolves in approximately 160 ns as the write completes with the assertion of the APB clock pulse.
Affected Conditions / Impacts
A write to RTCC_LOCK or RTCC_POWERDOWN may have unintended effects if the write is completed with the Low Energy Periph- eral clock enabled (RTCC in the CMU_LFECLKEN0 register is set to 1).
Workaround
To avoid this stability issue, configure the RTCC_LOCK and RTCC_POWERDOWN registers with the Low Energy Peripheral clock disabled (RTCC in the CMU_LFECLKEN0 register is cleared to 0).

This workaround is included in v5.1.0 or later of the Gecko SDK.

Resolution
There is currently no resolution for this issue.

RTCC_E205 – Wrap Event Can Be Missed

Description of Errata

The RTCC main counter can miss a CC1 wrap event (CCV1TOP bitfield in the RTCC_CTRL register set to 1) if one of the following registers are written in the same cycle as the wrap event: RTCC_CTRL, RTCC_CNT, RTCC_TIME, RTCC_DATE, RTCC_PRECNT, RTCC_IFC, RTCC_IFS, RTCC_CCx_CCV, RTCC_CCx_CTRL, RTCC_CCx_TIME, RTCC_CCx_DATE, RTCC_CMD, RTCC_RETx_REG.
Affected Conditions / Impacts
Systems using the CC1 wrap event feature may miss events if an affected register is written immediately before a wrap occurs.
Workaround
There are two workarounds to this issue:

•   Do not use the CC1 wrap event feature (CCV1TOP in RTCC_CTRL should be cleared to 0).

•   Alternatively, do not write to any of the affected registers when the counter is about to wrap. This means that firmware must check that RTCC_CNT is not close to RTCC_CC1_CCV before writing the register.

Resolution
There is currently no resolution for this issue.

TIMER_E202 — Continuous Overflow and Underflow Interrupts in Quadrature Counting Mode

Description of Errata

When the TIMER is configured to operate in quadrature decoder mode with the overflow interrupt enabled and the counter value (TIM- ER_CNT) reaches the top value (TIMER_TOP), the overflow interrupt is requested continuously even if the interrupt flag (TIM- ER_IF_OF) is cleared. Similarly, if the underflow interrupt is enabled and the counter value reaches zero, the underflow interrupt is requested continuously even if the interrupt flag (TIMER_IF_UF) is cleared. The interrupt can be cleared only after the counter value has incremented or decremented so that the overflow or underflow condition no longer applies.
Affected Conditions / Impacts
Because the counter is clocked by its CC0 and CC1 inputs in quadrature decoder mode and not the prescaled HFPERCLK, overflow and underflow events remain latched as long as TIMER_CNT remains at the value that triggered the overflow or underflow condition. Until the counter is no longer in the overflow or underflow condition, it is not possible to clear the associated interrupt flag.
Workaround
Short of disabling the relevant interrupts, the simplest workaround is to manually change TIMER_CNT so that the overflow or under-flow condition no longer exists. Insert the following or similar code in the interrupt handler for the timer in question (TIMER0 in this case) to do this:
uint32 intFlags = TIMER_IntGet(TIMER0);

if((intFlags & TIMER_IF_OF) && (TIMER0->CNT == TIMER0->TOP)) TIMER0->CNT = 0;

if((intFlags & TIMER_IF_UF) && (TIMER0->CNT == 0x0)) TIMER0->CNT = TIMER0->TOP;

|
It may be necessary for firmware to account for this adjustment in calculations that include the counter value.
Resolution
There is currently no resolution for this issue.

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 because 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.

USART_E205 — Possible Data Transmission on Wrong Edge in Synchronous Mode

Description of Errata

If the USART is configured to operate in synchronous mode with…

1. USART_CLKDIV_DIV = 0 (clock = fHFPERCLK ÷ 2)

2. USART_CTRL_CLKPHA = 0

3. USART_TIMING_CSHOLD = 1

…and data is loaded into the transmit FIFO (say, by the LDMA) at the exact same time as the USART state machine begins to insert the requested one bit time extension of chip select hold time (USART_TIMING_CSHOLD = 1), the first bit of the new data word is incorrectly transmitted on the leading clock edge of the subsequent data bit and not the trailing clock edge of the current data bit.

Affected Conditions / Impacts
Reception of each data bit by the slave is tied to a specific clock edge, thus the late transmission by the master of the first bit of a word may cause the slave to receive the incorrect data, especially if the data setup time for the slave approaches or exceeds one half the shift clock period.
Workaround
Because there is no way to specifically time a write to the transmit FIFO such that it does not occur when the USART state machine changes state, use one of the following workarounds to avoid the risk for data corruption described above:

•   Set USART_CLK_DIV > 0.

•   Use USART_TIMING_CSHOLD = 0 or USART_TIMING_CSHOLD > 1.

•   Use USART_CTRL_CLKPHA = 1. This option is particularly useful with SPI flash memories as many support operations in both the CLKPOL = CLKPHA = 0 and CLKPOL = CLKPHA = 1 mode.

Resolution
There is currently no resolution for this issue.

USART_E206 — Additional SCLK Pulses Can Be Generated in USART Synchronous Mode

Description of Errata

When inter-character spacing is enabled (USART_TIMING_ICS > 0) and USART_CTRL_CLKPHA = 1 in synchronous master mode, an extra clock pulse is generated after each frame transmitted except the last (that frame which when sent results in both the transmit FIFO and transmit shift register being empty).
Affected Conditions / Impacts
The extra clock pulse generated at the end of the first frame would cause a slave device to clock in the first bit of the next frame it expects to receive even though the USART is not yet driving that data. The slave would lose synchronization with the master and erroneously receive all frames after the first.
Workaround
Do not enable inter-character spacing when CLKPHA = 1. If a delay between frames is necessary, insert one manually with a software delay loop. Data cannot be transmitted using DMA in this case.
Resolution
There is currently no resolution for this issue.

WDOG_E201 – Clear Command is Lost Upon EM2 Entry

Description of Errata

If the device enters EM2 while the clear command is still being synchronized, the watchdog counter may not be cleared as expected.
Affected Conditions / Impacts
If the watchdog counter is not cleared as expected, the device can encounter a watchdog reset.
Workaround
Wait for WDOG_SYNCBUSY_CMD to clear before entering EM2.

Note that WDOG can be clocked from one of the low-frequency clock sources and will require additional time to enter EM2 when implementing this workaround.

Resolution
There is currently no resolution for this issue.

WTIMER_E201 — Continuous Overflow and Underflow Interrupts in Quadrature Counting Mode

Description of Errata

When the WITMER is configured to operate in quadrature decoder mode with the overflow interrupt enabled and the counter value (WTIMER_CNT) reaches the top value (WTIMER_TOP), the overflow interrupt is requested continuously even if the interrupt flag (WTIMER_IF_OF) is cleared. Similarly, if the underflow interrupt is enabled and the counter value reaches zero, the underflow inter- rupt is requested continuously even if the interrupt flag (WTIMER_IF_UF) is cleared. Only after the counter value has incremented or decremented so that the overflow or underflow condition no longer applies can the interrupt be cleared.
Affected Conditions / Impacts
Because the counter is clocked by its CC0 and CC1 inputs in quadrature decoder mode and not the prescaled HFPERCLK, overflow and underflow events remain latched as long WTIMER_CNT remains at the value that triggered the overflow or underflow condition. Until the counter is no longer in the overflow or underflow condition, it is not possible to clear the associated interrupt flag.
Workaround
Short of disabling the relevant interrupts, the simplest workaround is to manually change WTIMER_CNT so that the overflow or underflow condition no longer exists. Insert the following or similar code in the interrupt handler for the timer in question (WTIMER0 in this case) to do this:
uint32 intFlags = TIMER_IntGet(WTIMER0);

if((intFlags & WTIMER_IF_OF) && (WTIMER0->CNT == WTIMER0->TOP)) WTIMER0->CNT = 0;

if((intFlags & WTIMER_IF_UF) && (WTIMER0->CNT == 0x0)) WTIMER0->CNT = WTIMER0->TOP;

It may be necessary for firmware to account for this adjustment in calculations that include the counter value.
Resolution
There is currently no resolution for this issue.

Resolved Errata Descriptions

This section contains the previous errata for EFR32FG13 devices. For errata on the 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.  ****

Current Errata Descriptions

ADC_E222 – ADC EM2 Wakeup on a Comparator Match Disables EM2 Entry

Description of Errata

If the ADC wakes up the system from EM2 on a comparator flag match (CMPEN must be set in SINGLECTRL/SCANCTRL), the wake-up handler will not be able to clear this EM2 wakeup request. This results in the core immediately exiting EM2 on subsequent EM2 entry.
Affected Conditions / Impacts
Systems using the ADC comparator flag match may not be able to enter EM2.
Workaround
To clear the wakeup request, the wakeup handler must do one of the following:

•   Disable CMPEN in the SINGLECTRL/SCANCTRL register.

•   Reset the ADC FIFO.

•   Continue performing conversions until an incoming conversion does not pass the CMP threshold set in CMPTHR.

When one of these conditions has been met, the comparator can be re-enabled (if it was disabled) and the core can enter EM2.

Resolution
This issue is resolved in revision B devices.

ADC_E224 – ADC Warm-Up Ready Can Cause IDAC, ACMP, or CSEN to Not Function

Description of Errata

The IDAC, ACMP, or CSEN modules use the warm-up timing module in the ADC to determine when the peripherals are ready for use. However, if the ADC is enabled first, this timing module can fail to properly handshake with a low probability, causing the IDAC, ACMP, or CSEN modules to never finish warming up. The ADC is not affected by this issue and will always be available after it is enabled.
Affected Conditions / Impacts
Systems using the IDAC, ACMP, or CSEN modules in conjunction with the ADC can see intermittent failures where these modules do not operate.
Workaround
To work around this issue, enable the IDAC, ACMP, or CSEN modules before enabling the ADC. This will ensure the handshaking logic between the ADC and other modules functions correctly.
Resolution
This issue is resolved in revision C devices.

ADC_E225 – Using the ADC in High-Accuracy Bias Mode Will Force All Analog Peripherals to High-Accuracy Bias Mode

Description of Errata

Using the ADC in high-accuracy bias mode (GPBIASACC in ADCn_BIASPROG cleared to 0) forces all other analog peripherals into high-accuracy bias mode. These peripherals will then draw additional current.

The data sheet’s current consumption numbers are currently specified with this additional current consumption included. When the updated devices are available, the device data sheet will be updated with the reduced current consumption specifications.

Affected Conditions / Impacts
Systems using the ADC in high-accuracy bias mode may see higher current consumption than expected when other analog peripherals not using high- accuracy bias mode are in use.
Workaround
There is currently no workaround for this issue.
Resolution
This issue is resolved in revision C devices.

DBG_E203 – CRC Debug Command Available

Description of Errata

The CRC Debug Command is always available, even when the Debug Access Port (DAP) is locked, enabling outside systems to re-quest a CRC of the memory at any time. The memory of the device is not accessible when the DAP is locked.
Affected Conditions / Impacts
External systems may CRC the memory contents at any time.
Workaround
There is currently no workaround for this issue.
Resolution
This issue is resolved in revision B devices.

EMU_E211 – Radio Clocks Remain Disabled After Voltage Scaling

Description of Errata

To avoid the radio clocks from causing issues at low voltage, hardware automatically disables the radio clocks while scaling down to Voltage Scale Level 0 (1 V). However, this lock is never released, disabling the radio until the next full reset.
Affected Conditions / Impacts
If the device voltage is scaled below Voltage Scale Level 2 (1.2 V), then the device scales the voltage back up to use the radio, and the radio will not function.
Workaround
To work around this issue, do not use voltage scaling when using the radio.
Resolution
This issue is resolved in revision B devices.

RMU_E203 – AVDD Ramp Issue

Description of Errata

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

For example configurations and waveforms that are more likely to result in this issue, see the following Knowledge Base article: http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/RMU-E203-AVDD-Ramp- Issue/ta-p/197340

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.

Affected Conditions / Impacts
Systems may intermittently see the device fail to start, reset, or respond. The current draw of the device in this state is ~100 µA and DECOUPLE will be fully powered (~1.2 V). The device will not execute any code in this state.
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 must be configured to hard reset mode. This can be accomplished as part of the firmware image programmed to the device (lock bits area) or 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);

}

|
There is currently no software workaround for all potential failure mechanisms. The software workaround included in the Knowledge Base article will prevent failure in some scenarios. See the Knowledge Base article for more information:

http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/RMU-E203-AVDD-Ramp- Issue/ta-p/197340

Resolution
This issue is resolved in revision C devices.

TRNG_E202 — Standards Non-compliance

Description of Errata

The TRNG module may either fail to generate random numbers or generate random numbers with AIS-31 error flags. This is because the TRNG has two potential issues:

•   Non-Compliance with NIST SP800-90B

The TRNG entropy source may not be sufficient to pass the start-up tests and will not place any data in the FIFO.

•   Non-Compliance with AIS-31

The TRNG entropy source may be sufficient to pass the start-up tests, but insufficient to pass the AIS-31 test. It will place some data in the FIFO and indicate an AIS-31 error.

In both cases, the TRNG will cause the mbed TLS random number generator to return an error code and no data. The TRNG module, therefore, is non- functional and should not be used.

Affected Conditions / Impacts
Application software that uses the mbed TLS random number generator may return no data either with or without an error code. Soft- ware that accesses the TRNG module directly by using the public CMSIS registers will either receive no data or data with AIS-31 error flags.
Workaround
There is no workaround that is NIST SP800-90B or AIS-31 compliant. Silicon Labs has implemented the use of alternative entropy sources to add entropy to the medals entropy collector in Gecko SDK version 2.3. The TRNG module should not be used directly. Customer application code should rather use the mbedTLS entropy collector API in Gecko SDK version 2.3 and later.
Resolution
This issue is resolved in revision D devices.

USART_E203 — DMA Can Miss USART Receive Data in Synchronous Mode

Description of Errata

If the USART is operating in synchronous mode, it can drop received data before the DMA has a chance to read it under the following conditions:

•   Synchronous master sample delay is enabled (USARTn_CTRL_SMSDELAY = 1) to improve timing at higher clock rates.

•   The receive FIFO is already full, and the receive data DMA request (USARTnRXDATAV) is asserted.

•   The transmit shift register is clocking out the last frame to be sent, the transmit FIFO is empty, and the transmit data DMA request (USARTnTXBL) is asserted.

•   The transmit data DMA request arrives before the receive data DMA request (the transmit FIFO empties before the receive data DMA request is asserted).

•   A higher priority peripheral DMA request arrives while processing the transmit data DMA request but before the receive data DMA request is processed.

Because the incoming peripheral DMA request has higher priority than the USART DMA requests but cannot interrupt a DMA request that is already in progress (the transmit data DMA request), it will be processed before the receive data DMA request, thus causing the USART to drop an incoming frame (or frames) since the receive FIFO is already full.

Affected Conditions / Impacts
In systems that use the USART in synchronous mode with the master sample delay feature (USARTn_CTRL_SMSDELAY = 1) and that use the DMA to manage both the USART transmitter and receiver, as well as other peripherals with higher request priorities, the USART can drop an incoming frame (or frames) if the DMA is not able to process the receive data requests to empty the receive FIFO when it is full.
Workaround
Assign a higher priority to the DMA channel servicing the received data DMA requests such that it is processed before the channel servicing transmits data DMA requests and any channels servicing requests associated with any other peripherals that could potentially stall a USART synchronous transfer that is already in progress. Set LDMA_CHx_CTRL_IGNORESREQ = 1 for the transmit data channel so that the LDMA accumulates multiple requests from the transmitter and services them with a single transfer cycle. This causes the LDMA to fill the USART transmitter’s FIFO only when it is empty instead of each and every time space becomes available.
Resolution
This issue is resolved in revision D devices.

Revision History

Revision 0.1
November 2016

• Initial release.

Revision 0.2
May 2017

• Added ADC_E224, ADC_E225, DBG_E204, RMU_E202, and RMU_E203.

Revision 0.3
August 2017

• Updated to product revision C.

Revision 0.4
March 2018

• Updated the workaround in RMU_E202.

Revision 0.5
May 2018

• Added TRNG_E202.

Revision 0.6
November 2018

• Added ADC_E228, CSEN_E201, CSEN_E202, EMU_E214, I2C_E202, I2C_E203, I2C_E204, I2C_E205, I2C_E206, USART_E203, and USART_E204.

Revision 0.7
May 2019

• Updated to product revision D.
• Resolved TRNG_E202 and USART_E203.

Revision 0.8
January 2020

• Added LES_E201, TIMER_E202, USART_E205, and WTIMER_E201.
• Migrated to new errata document format.

Revision 0.9
April 2020

• Added EMU_E220.

Revision 1.0

September 2020

• Added I2C_E207, USART_E206, and WDOG_E201.

IoT Portfolio

• www.silabs.com/IoT

SW/HW

• www.silabs.com/simplicity

Quality

• www.silabs.com/quality

Support & Community

• www.silabs.com/community

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 to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance of the product. Silicon Labs shall have no liability for the consequences of the use of the information supplied in this document. This document does not imply or expressly grant any license to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is required, or Life Support Systems 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. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to the use of a Silicon Labs product in such unauthorized applications.

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®, Gecko OS, Gecko OS Studio, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress®, Zentri, the Zentri logo and Zentri DMS, 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. Wi-Fi is a registered trademark of the Wi-Fi Alliance. 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

References

• Silicon Labs

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>