AN961: Bringing Up Custom Devices for

the EFR32MG and EFR32FG Families

This application note describes how to initialize a piece of custom

hardware (a “device”) based on the EFR32MG and EFR32FG

families so that it interfaces correctly with a network stack. The

same procedures can be used to restore devices whose settings

have been corrupted or erased.

KEY POINTS

• Information required before board bring-up

• Setting manufacturing tokens

• Bootloading

• Performing functional testing

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

1. Introduction

Before an EFR32-based product such as a member of the Wireless Gecko or Flex Gecko families (hereafter EFR32) can be initialized

and tested, manufacturing tokens within the EFR32 User Data Page and the Lock Bits Page must be configured. Similarly, before any

application specific code can be programmed into the EFR32 flash, a board header needs to be created either manually or from the

Application Builder tool set. In order to perform these tasks, the product design team must know how the EFR32 is to be used in the

wireless system.

In particular, the design team must know the following:

• PCB Manufacturing-specific information (serial number, product numbers, EUI, and so on)

• Bootloader architecture (serial dataflash)

• External components in the RF Path (PA, LNA, and so on)

• 38.4 MHz crystal oscillator specification and a CTUNE value to match your crystal so you hit the center frequency

• Application security tokens (Keys, certificates, and so on)

Note: Even though the EFR32 flash is fully tested during production test, the flash contents in the main flash block are not set to a

known state before shipment. The User Data and Lock Bits pages are erased to all 0xFF, except in kits where they might be preloa-

ded with configuration values such as CTUNE.

AN961: Bringing Up Custom Devices for the EFR32MG and EFR32FG Families

Introduction

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