EFR32 Wireless System#
Once the hardware design of a custom device has been completed, the assembled product is ready for test and functional validation. Before testing, developers must understand how the device will operate at both the device-level and system-level. The following table describes the different items that developers should know before board bring-up.
Information | Required or Optional | Description |
|---|---|---|
Device Level | ||
Product Information | Optional | Most products have unique serial numbers as well as generic product codes that might be stored in the EFR32. This information might include items such as where and when the device was assembled, a product serial number, and product name. |
Custom EUI | Optional | IEEE 64-bit unique number. Each EFR32 comes with an EUI programmed into the Device Information Page. Customers that have their own IEEE address block can use it in place of the Device Information Page’s EUI. |
RF Component Information | Required | If the product uses external PAs or LNAs, then developers must know the pin-connections between the off-chip components and the EFR32. They should also understand the LNA Gain as it will be used to offset the clear channel assessment (CCA) threshold. |
Protocol-Specific Information | Optional | If developing a product using the Zigbee networking protocol, obtain a Zigbee-assigned manufacturer code before testing the application. |
System Level | ||
Bootloader Option | Required | Silicon Labs offers several bootloading options for different system designs. For more information, see Bootloader Fundamentals. |
System Security | Optional | If device-level security is required for the product, determine necessary security settings and keys before setting up the device. |
As detailed in the above table, Silicon Labs offers its customers an opportunity to guarantee a device’s uniqueness on the network. In addition, it allows customers a way to store product descriptions, manufacturer-specific information and device information.