EFM32 Series 0:

For external references, the calibration must be determined for the specific application and set by the user.

For the Unbuffered 2xVDD reference, there is no hardware gain calibration. Calibration can be done by software after taking a sample.

EFM32 Series 1 and EFR32 Wireless Gecko Series 1:

VBGR, VDDXWATT, VENTROPY, VBGRLOW, VREFP, VREFPWATT, VERFPN, and VREFPNWATT are references for advanced full-scale voltage configuration. The advanced full-scale configurations are enabled by programming the REF bit-field in ADCn_SINGLECTRL or ADCn_SCANCTRL register to the CONF option.

For external references (VREFP, VREFPWATT, VERFPN, and VREFPNWATT), the calibration must be determined for the specific application and set by the user. Calibration data is also not available for the internal references VBGR, VENTROPY, and VBGRLOW.

For the AVDD, 2xAVDD, and VDDXWATT references, there is no hardware gain calibration. Calibration can be done by software after taking a sample.

An integrated DC-DC buck converter is an option on most Series 1 EFM32 and EFR32 devices. While this term is used across the EFM32/EFR32 documentation and often shortened to "DCDC", it's important to note that what's present on the chip still requires an inductor and a capacitor to generate the output voltage to which the DCDC is programmed.

In fact, what is actually seen on the VREGSW pin, which is an output from the MCU, is not the regulated voltage itself but the switching waveform associated with the DCDC. This waveform is, obviously, very different from what is seen at the actual output of the converter, which is the regulated voltage seen after the inductor and where the capacitor is connected to ground, e.g. the VDCDC node as shown in the figure below:

Programming of the DC-DC converter and device power configurations are covered in Application Note 0948: EFM32 and EFR32 Series 1 Power Configurations and DC-DC, but one item not addressed is the waveform seen on and voltage swing of the VREGSW pin. While the frequency can vary, the output waveform looks like this:

The voltage swing on VREGSW can vary, as well, including over temperature, but can be expected to range from -1V to VREGVDD + 1V, where the under/overshoot is due to the switching current flowing through the ESD/body diode during the DCDC powertrain's dead time.

Does the RAM on any EFM32, EFR32, or EZR32 devices have ECC or parity?

1. No EFM32 Series 0 or EZR32 devices have RAM parity or ECC support.

2. No EFR32 Series 1 devices have RAM parity or ECC support.

3. RAM0 (128 KB) and RAM1 (128 KB) on the EFM32 Giant Gecko 11 (GG11) device has 2-bit detect/1-bit correct ECC support. RAM2 (256 KB) on this device does not have parity or ECC support.
   
   No other EFM32 Series 1 devices have RAM parity or ECC support.

ECC is enabled by the MSC_ECCCTRL register on EFM32GG11, and ECC errors are reported for RAM0 and RAM1, respectively, by the MSC_RAMECCADDR and MSC_RAM1ECCADDR registers. Interrupt flag and control bits for RAM errors are present in the MSC_IEN, MSC_IF, MSC_IFC, and MSC_IFS registers.

What is the soft error rate (SER) or failure in time (FIT) rate for the RAM on EFM32 or EFR32 Series 1 devices?

The fundamental RAM bit cell design on all EFM32 and EFR32 Series 1 devices has a failure in time (FIT) rate of 510.

When ADC operates in synchronous mode:

• The adc_clk_sar should be > 32 kHz and <= 16 MHz.
• The ADC_CLK is equal to the ADC HFPERCLK.

When ADC operates in asynchronous mode:

• The adc_clk_sar should be > 32 kHz and <= 16 MHz.
• The ADC HFPERCLK must be at least 1.5 times higher than the ADC_CLK (can be AUXHFRCO, HFXO or HFSRCCLK).

For example, the maximum ADC_CLK frequency in asynchronous mode is 10.67 MHz (16 x 2/3) if the ADC HFPERCLK frequency is 16 MHz.

The emlib function ADC_Init() will issue ASSERT error if the adc_clk_sar and ADC_CLK frequency cannot meet the ADC synchronous or asynchronous mode criteria.

Example code to setup ADC in asynchronous mode with AUXHFRCO. 

// Select AUXHFRCO for ADC ASYNC mode so that ADC can run on EM2
CMU->ADCCTRL = CMU_ADCCTRL_ADC0CLKSEL_AUXHFRCO;
// Select AUXHFRO band
CMU_AUXHFRCOFreqSet(cmuAUXHFRCOFreq_16M0Hz);

// Init ADC in ASYNC mode, ADC_CLK = AUXHFRCO, adc_clk_sar = 4 MHz
ADC_Init_TypeDef init = ADC_INIT_DEFAULT;
init.timebase = ADC_TimebaseCalc(CMU_AUXHFRCOBandGet());
init.prescale = ADC_PrescaleCalc(4000000, CMU_AUXHFRCOBandGet());
init.em2ClockConfig = adcEm2ClockOnDemand;
ADC_Init(ADC0, &init);

The I2C module on EFM32 and EFR32 devices provide an interface between the MCU and a serial I2C-bus. It is capable of acting as both a master and a slave and supports multi-master buses. Silabs provided examples project via SDK or Github to demonstrate both master and slave configurations of the EFM32/EFR32 I2C peripheral.

And also a higher level kit driver I2CSPM (I2C simple poll-based master mode driver) provided with a set of APIs for easily initializing the I2C peripheral as master mode and performing the I2C transfer, this KBA provides a step by step guide for how to extend the I2C master mode functionality with your project.

Please follow the steps below on how to perform the I2C transfer with the I2CSPM driver.

1. Create your project in Simplicity Studio.

2. Copy the i2cspm.c and i2cspm.h from the \hardware\kit\common\drivers folder in the SDK to your project.

3. Include the header file "i2cspm.h" to your project file.

4. Initialize the I2C peripheral as master mode with the API I2CSPM_Init().

5. Define the I2C Master mode transfer sequence which depends on the required I2C transfer.

6. Perform the I2C transfer with the API I2CSPM_Transfer().

The enclosed example project for EFM32PG12 demonstrates how to perform a one byte I2C read transfer, also the code snippet posted here for a quick overview. The parameter "addr" represents I2C slave address. 

It supports 7-bit or 10-bit I2C address, the value of the "addr" here should be the I2C slave address with one bit left shifted. For example, if you need to communicate with the I2C slave addressed 0x29, the value of "addr" should be 0x52.

static I2C_TransferReturn_TypeDef i2cReadByte(I2C_TypeDef *i2c, uint16_t addr, uint8_t command, uint8_t *val)
{
  I2C_TransferSeq_TypeDef    seq;
  I2C_TransferReturn_TypeDef sta;
  uint8_t                    i2c_write_data[1];
  uint8_t                    i2c_read_data[1];

  seq.addr  = addr;
  seq.flags = I2C_FLAG_WRITE_READ;
  /* Select command to issue */
  i2c_write_data[0] = command;
  seq.buf[0].data   = i2c_write_data;
  seq.buf[0].len    = 1;
  /* Select location/length of data to be read */
  seq.buf[1].data = i2c_read_data;
  seq.buf[1].len  = 1;

  sta = I2CSPM_Transfer(i2c, &seq);
  if (sta != i2cTransferDone)
  {
    return sta;
  }
  if (NULL != val)
  {
    *val = i2c_read_data[0];
  }
  return sta;
}

As shown in the screenshot below, EFM32PG12 writes a command 0x20 to the Slave device and then read back one byte.

Get more information about the I2CSPM from the online documentation here:
http://devtools.silabs.com/dl/documentation/doxygen/5.5/efm32pg12/html/group__I2CSPM.html

Note: In the GPIO module of the EFM32 the internal pull-up resistors have been enabled, hence external pull-up resistors are not necessary to make the example work. However, external resistors are generally preferable as they keep the lines defined at all times.

For EFM32PG1, the USART has a 15-bit integral and 5-bit fractional clock divider to allow the USART clock to be controlled more accurately than what is possible with a standard integral divider.

However, the fractional part of divider can only use for asynchronous operation (UART), if the fractional part is used on synchronous operation (e.g. SPI master), it could cause half clock cycles to exceed a specified limit and thus potentially violate specifications for the slave device could tolerate. Especially for high speed use case that need a very low divider value.

In order to avoid this kind of issue, in emlib, the fractional part of the clock divider for clock generation is suppressed in the function USART_BaudrateSyncSet(), thus only the bit-rate that equals HFPERCLK/2 divided by an integral without remainder is available.

Suppose the HFCLK is 38.4MHz, and HFPERCLK is 19.2MHz which is prescaled HFCLK, what the available bit-rate of SPI master mode are 19.2/2MHz, 19.2/4 MHz, etc.

In some special situations, the fractional clock division may be useful even in synchronous mode (especially for low speed use case where a very high divider value is needed. In that case, the high/low asymmetry of the SPI clock phenomena is not heavy), but in those cases the bit-rate must be directly adjusted with the API of USART_BaudrateCalc().

Question

How can I use the LDMA to perform transfers that don't have presets in em_ldma.h?

Answer

The em_ldma.h LDMA descriptors (ex. LDMA_DESCRIPTOR_SINGLE_M2M_WORD) do not determine any hardware capabilities, they are merely descriptor setting presets that fit the average use case of the LDMA. You can still set up the LDMA to do transfers that don't fit any of these presets, such as a linked Memory to Peripheral descriptor of halfwords.

To do this, you have two basic options; pick a preset that is close to your desired setup and make slight changes, or build your descriptor from scratch.

Using Presets

First, let's look at what our preset options are.  There are three settings that change from one preset to another: size (WORD, HALF, BYTE), link option (SINGLE, LINKABS, LINKREL), and type.  The available options for each type is listed below:

• M2M (Memory to Memory)            - all three link options are available for all three data sizes  
• M2P/P2M (Memory to Peripheral) - SINGLE and LINKREL options are available for BYTE only
• P2P (Peripheral to Peripheral)      - only SINGLE transfers are available for BYTE only
• WRI (Write transfer)                      - all three link options are available, and the size is irrelevant
• SYNC (Synchronous transfer)      - all three link options are available, and the size is irrelevant

As the name suggests, all that the "size" option affects is the .xfer.size variable.  "WORD" presets set .xfer.size to ldmaCtrlSizeWord, "HALF" use ldmaCtrlSizeHalf, and "BYTE" use ldmaCtrlSizeByte.

The "link" option affects if linking is used, and how the next descriptor is determined if there is linking.  "SINGLE" disables linking while "LINKREL" and "LINKABS" are different ways of indicating the destination of the link.  This is seen through 3 variables: linkMode, link, and linkAddr.

The "type" option affects six variables, most notably structType.  For WRI and SYNC descriptors, structType is set accordingly and therefore many of the other registers don't matter.  For all the others, we see the differences in the following table:

So what we see is that with Memory to Memory transfers, the assumption is that the user wants the transfer to be fast.  It happens as soon as it's loaded, it moves all the data at once, and it doesn't interrupt at the end (unless it's the last descriptor in the link).

With peripheral transfers, the assumption is that the user wants transfers spread out over multiple requests.  The transfers only start when requested by a signal, and an interrupt is requested when the descriptor has finished (even if it's not the last descriptor in the link).  Also, the peripheral side of the transfer should have a step size of "None", so that the transfers always use the same peripheral register.

Building from Scratch

You also have the option to define the value of each variable inside the LDMA_Descriptor_t typedef.  While this does require you to know exactly what you want, it makes it easier to tell at a glance what any given variable is being set to (instead of having to look inside em_ldma.h to find out).  An example of how to do this is given below.

An Example

Let's say we want to use the LDMA to transfer halfwords from memory to a peripheral register.  We don't want interrupts or automatic transfers, we want this transfer to be part of a relative linked list of transfers, and we want separate signals for each halfword. 

Ideally we could use "LDMA_DESCRIPTOR_LINKREL_M2P_HALF", but unfortunately for us, that doesn't exist.  So instead, we'll look at modifying either LINKREL_M2M_HALF or LINKREL_M2P_BYTE, because these are the two closest presets to what we want.

LINKREL_M2M_HALF is convenient because it will set us up with the correct data size and doneIfs settings. However, because it assumes we want fast, large transfers, it has structReq and reqModeAll set, which we would have to clear.  Also, we would have to set dstInc to None to ensure that all our individual transfers are to the same peripheral register.

  // Declare local variables
  uint32_t source, dest, xferSize;

  // Setup using preset
  LDMA_Descriptor_t myDescriptor = (LDMA_Descriptor_t)LDMA_DESCRIPTOR_LINKREL_M2M_HALF(
        &source, 
        &dest, 
        xferSize, 
        1);

  // Edit preset to fit individual needs  
  myDescriptor.xfer.structReq = 0;
  myDescriptor.xfer.reqMode = ldmaCtrlReqModeBlock;
  myDescriptor.xfer.dstInc = ldmaCtrlDstIncNone;
     

LINKREL_M2P_BYTE is convenient because it will set us up with the correct peripheral assumptions; we want structReq off, reqMode Block, and dstInc None.  Here, we would have to manually clear doneIfs and set size.

  // Declare local variables
  uint32_t source, dest, xferSize;

  // Set up using preset
  LDMA_Descriptor_t myDescriptor = (LDMA_Descriptor_t)LDMA_DESCRIPTOR_LINKREL_M2P_BYTE(
        &source, 
        &dest, 
        xferSize, 
        1);

  // Edit presets to fit individual needs
  myDescriptor.xfer.size = ldmaCtrlSizeHalf;
  myDescriptor.xfer.doneIfs = false;

We see that in this case, it is slightly easier to edit LINKREL_M2P_BYTE than it is to edit LINKREL_M2M_HALF.

If you want to build your descriptor from scratch, it might look like this:

  myDescriptor = (LDMA_Descriptor_t)
  {                                                                 
    .xfer =                                                        
    {                                                               
      .structType   = ldmaCtrlStructTypeXfer,                       
      .structReq    = 0,                                            
      .xferCnt      = (count) - 1,                                  
      .byteSwap     = 0,                                            
      .blockSize    = ldmaCtrlBlockSizeUnit1,                       
      .doneIfs      = 0,                                            
      .reqMode      = ldmaCtrlReqModeBlock,                           
      .decLoopCnt   = 0,                                            
      .ignoreSrec   = 0,                                            
      .srcInc       = ldmaCtrlSrcIncOne,                            
      .size         = ldmaCtrlSizeHalf,                             
      .dstInc       = ldmaCtrlDstIncNone,                            
      .srcAddrMode  = ldmaCtrlSrcAddrModeAbs,                       
      .dstAddrMode  = ldmaCtrlDstAddrModeAbs,                       
      .srcAddr      = (uint32_t)(src),                              
      .dstAddr      = (uint32_t)(dest),                             
      .linkMode     = ldmaLinkModeRel,                              
      .link         = 1,                                            
      .linkAddr     = (linkjmp) * 4                                 
    }                                                               
  };

As we can see, it's probably best to build your own descriptor if you want to do something unusual, but if you just want to get one up and running quickly, there's likely a preset that will work for you with minimal changes necessary.

On series 0 devices with a backup power domain, it is possible to adjust the backup-entry and backup-exit threshold voltages by using a calibration algorithm described in the reference manual. However, these instructions omit two steps that must be completed for the process to work correctly.

1. The DAC must be configured before BODCAL is cleared.
2. The DAC output mode must be set to ADC

If these steps are not followed, setting BODCAL will immediately set the following flags in the RMU_RSTCAUSE register:

• BUBODUNREG
• BUBODUNREG
• BUBODBUVIN
• BUBODVDDDREG

Attached to this article is a program that shows how to perform this BU domain calibration.

The EFM32 STK Virtual COM (VCOM) port baud rate is fixed at 115200, N, 8, 1.

The EFM32G and EFM32TG STK do not support VCOM port.

For EFM32 STK (EFM32ZG, EFM32HG, EFM32PG1, EFM32PG12, and EFM32xG11) with 20-pin Simplicity Connector

• Set the DEBUG mode to OUT
• Connections between EFM32 STK and external device:

  EFM32 STK	External Device
  Virtual COM TX (pin 2 of Simplicity Connector)	UART TX
  Virtual COM RX (pin 4 of Simplicity Connector)	UART RX
  GND (pin 7 of Simplicity Connector or any GND pin on STK)	GND

For EFM32 STK (EFM32GG, EFM32LG, and EFM32WG) without 20-pin Simplicity Connector

• DEBUG mode is irrelavant
• Write a dummy program with below code to enable the EFM32 STK VCOM connection

  CMU_ClockEnable(cmuClock_GPIO, true);
  GPIO_PinModeSet(gpioPortF, 7, gpioModePushPull, 1);

   

• Connections between EFM32 STK and external device:

  EFM32 STK	External Device
  PE0 (EFM_BC_TX)	UART TX
  PE1 (EFM_BC_RX)	UART RX
  GND (any GND pin on STK)	GND