SILICON LABS AN718 PCB Resources – v5.5.0 – Simplicity Studio 5 Instructions

SILICON LABS AN718 PCB Resources – v5.5.0 – Simplicity Studio 5

Most customers have standard product manufacturing test flows, but some do not incorporate RF testing. This document describes the different options for integrating RF testing and characterization into your standard test flows. This application note is intended for Silicon Labs customers who are moving from the early prototype development stage to the manufacturing production environment and need assistance with manufacturing test. The specific target audience is senior manufacturing engineers and manufacturing managers who are investigating test processes for their Silicon Labs-enabled products. This document summarizes approaches to manufacturing tests for all Silicon Labs proto-cols and platforms. Additional detail is provided in AN700.1: Manufacturing Test Guide-lines for the EFR32 Family.

KEY POINTS

• Manufacturing test flow
• Test definitions
• Test recommendations
• Embedded Software tools
• Regulatory and Compliance Testing

Manufacturing Test Flow
PCB manufacturing testing has two primary objectives: verifying components are placed properly on the boards and verifying functionality of the boards. The overall goal is to maximize test coverage while minimizing test costs. Manufacturing testing parallels the product lifecycle in that each phase is unique and builds on the previous phase. The following figure shows the traditional product lifecycle and how the different phases of the manufacturing process align with it.

Silicon Labs recommends four phases of testing products according to the product lifecycle. Each phase has a purpose and builds off the previous stages.

1. Prototype : The objective of this phase is to fully verify the design on a small number of devices.
2. Characterization: This phase verifies the functionality of the product. Once the product has been fully characterized, volume testing is next. The two phases of volume manufacturing testing are low-volume and high-volume.
3. Low-volume : This phase contains a subset of the tests run during the characterization phase but with reduced test time and coverage.
4. High-volume: This phase is a much faster test, which allows for ease of test and scalability. The objective of these manufacturing test phases is to verify that components are placed properly on the boards. The tradeoffs for these phases discussed the next sections are the type of testing, test coverage, data collection, test application, test time, and test cost.

Phase 1 – Prototype Testing
The first phase of manufacturing test involves initial prototype testing, also known as design verification/validation. This involves product that has gone through its “first build” on a new product introduction (NPI) assembly line. This phase incorporates bench tests with test equipment and usually is not automated. Prototype testing usually involves the engineering design team. Therefore it is time consuming and expensive, but it is very important in verifying the product functionality.

As part of design verification, the product should be tested over the full environmental product requirements including temperature range and voltage supply range. The product should also be subjected to certification and compliance testing, which may include FCC, ETSI, CE, and any applicable protocol-specific compliance testing. Finally, this phase includes general qualification testing, according to JEDEC standards.

Phase I tradeoffs are as follows:

• Volume: First 5-50 boards
• Type of Testing: Bench test with test equipment, not necessarily automated
• Test Coverage: Full design verification
• Data Collection: Not necessarily automated but very detailed
• Test Application: Standalone application
• Test Time: Hours per device (or months for some qualification tests)
• Test Cost: Expensive

Phase II – Characterization Testing
The second phase of testing in the product lifecycle is characterization testing. The objective of this phase is to verify functionality and repeatability. During this phase, the hardware is manufactured in higher volume (on an NPI line or production assembly line). The assembled product is fully characterized with automated test programs to determine design performance and manufacturability, as well as to collect valuable test data to be used to help with setting test limits in later phases. This phase also provides yield expectations and provides valuable design for manufacturability (DFM) and design for test (DFT) feedback to the engineering design team.

Phase II tradeoffs are as follows:

• Volume: Next 500 to 1,000 boards, depending on the customer
• Type of Testing: Automated with test equipment
• Test Coverage: Full design verification
• Data Collection: Automated, datalogs
• Test Application: Standalone application or application test mode
• Test Time: 10–30 minutes per device
• Test Cost: Expensive

Phase IV – High Volume Manufacturing Testing
The fourth and final phase is high-volume manufacturing. During this phase, test time is crucial and only minimal testing may be required depending on the customer and the application. A Golden Node application (a known good device that can be used in test for repeatable measurements) can be developed to transmit and receive packets to and from a device under test (DUT) to verify basic functionality. To further reduce test time, a manufacturing library can be used to allow for a test mode within the application itself, thus avoiding multiple programming steps.

Phase IV tradeoffs are as follows:

• Volume: After 1,000 to 2,000 boards

• Type of Testing: Automated with subset of test equipment

• Test Coverage: Minimal, basic functionality
  Data Collection: Minimal data, still automated

• Test Application: Application test mode

• Test Time: Less than 1 minute per device

• Test Cost: Minimal

Test Definitions
Automated test is defined as a test method where test equipment and DUT are controlled by a PC. A test program on the PC controls the test equipment and DUT. The DUT is loaded with embedded software that allows the radio to be configured for particular tests. The tests can be divided into different types of tests— RF testing, DC testing, and peripheral testing.

• RF testing is any test specific to the operation and functionality of the radio (for example, transmitting and receiving Zigbee packets).
• DC testing is any test related to the voltage and current characteristics of the device or board (for example, active and sleep currents).
• Peripheral testing is any test not specific to RF or DC, like a sensor or an external crystal.
  For more details on the specific recommended tests, refer to AN700.1: Manufacturing Test Guidelines for the EFR32.

Test Recommendations

This section summarizes the functionality that should be tested on the hardware product, depending on the phase. These recommenda-tions are for SoC (System-on-Chip) products. Silicon Labs also offers EFR-based modules that are pre-certified or fully certified. In such cases, the customer’s end product will require limited RF testing depending on the region and its compliance to the regulatory standards. See AN1048: Regulatory RF Module Certifications for more information on module certifications and the required testing.

Prototype Testing
Prototype testing is necessary for all product designs. In this phase of testing, the design is verified across the full environmental product requirements, including temperature range and voltage supply range, as well as humidity range in some cases. This level of environmental testing may occur over several months, depending on the qualification requirements of the product. Certification and compliance testing may also be necessary in this phase of testing. External test houses are likely to be involved to support this testing. This phase fully verifies the design of the hardware and product that is being developed, and helps identify any design issues that need to be corrected before proceeding to the characterization testing phase.

Characterization Testing
Characterization testing is recommended for early production stages. In this phase of testing, the RF functionality (transmit and receive) should be characterized on all applicable channels or a subset of these channels, as well as at various transmit output power levels or receiver input power levels. This phase fully characterizes the hardware that is being developed, determines the tests to be executed in manufacturing test, determines the test limits of these tests, and flushes out any manufacturing or process issues that might be present.

Low-Volume Manufacturing Testing
Low-volume manufacturing testing is usually a subset of the characterization testing. A subset of the applicable channels or transmit output power levels can be tested to reduce the test time without compromising test coverage. For example, one channel/power level combination (likely mid-band at max power) can be measured for transmit and receive functionality.
The results from the characterization phase of testing help determine not only what should be tested in the manufacturing phase but also the test limits to be applied to certain tests. For example, if a particular test does not fail at all during the characterization phase, it can be omitted from the manufacturing phase altogether. Also, if it is determined that a particular test will fail all channels if it fails at all, testing can be reduced from all channels to a single channel, most likely mid-band.

High-Volume Manufacturing Testing
High-volume manufacturing testing is much simpler than characterization testing or low-volume manufacturing testing. The hardware design and manufacturing process have already been proven, so the product now just requires a quick “go/no go” transmit and receive functional test to verify operation.

Embedded Software Tools
The embedded software application could be a standalone test application or the customer’s own application with a test mode included. Silicon Labs provides different test applications depending on the protocol being used. These applications are discussed in detail in AN700.1: Manufacturing Test Guidelines for the EFR32. The following table summarizes the test tools provided by Silicon Labs.

Table 4-1. Software Tools Available for All Protocols and Platforms

UG409; AN972; INS14283
Direct Test Mode (DTM)| EFR32| Bluetooth LE| AN1046 (v2.x); AN1267

(v3.x)

NodeTest
The NodeTest standalone application is provided with the EmberZNet SDK (Software Development Kit). Silicon Labs recommends Node-Test for any test stage in which the customer’s Zigbee application is not yet mature enough to include a test mode. NodeTest provides a serial command line interface to the Silicon Labs device. Instructions for using NodeTest are provided in AN1019: Using the NodeTest Application.

Manufacturing Library
Silicon Labs recommends that customers use the manufacturing library in mature applications, regardless of the testing phase. Customers without mature applications can build a simple Zigbee sample application with the manufacturing library enabled to access this function-ality. The manufacturing library provides access to a test mode within the application and removes the need for multiple application bootloads or multiple programming steps within the manufacturing process. The manufacturing library is available as a configurable plugin in the EmberZNet SDK. The guidelines for enabling the manufacturing library plugin and using the manufacturing library CLI commands for manufacturing tests are provided in AN1162: Using the Manufacturing Library for EmberZNet.

RAILtest
The RAILtest standalone application is provided with the Flex SDK. It provides customers with a simple tool for testing the radio and the functionality of the RAIL library. For any advanced usage customers should write their own software with a custom radio configuration. RAILtest is documented in UG409: RAILtest User’s Guide, AN972: EFR32 RF Evaluation Guide, and INS14283: Bring- up/Test HW De-velopment.

Direct Test Mode protocol (DTM)
The DTM protocol is defined in the Bluetooth specification as a means for testing the radio performance of Bluetooth low energy products Bluetooth- enabled Silicon Labs EFR32xG SoCs and the BGM/MGM modules support both the DTM upper and lower testers. DTM testing is described in AN1046: Radio Frequency Physical Layer Evaluation in the Bluetooth® SDK v2.x and AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x.

Radio Frequency Regulatory and Compliance Testing
Customers need to perform RF measurements to validate and certify the product’s compliance with the regulatory rules. The level of testing depends on the Silicon Labs product. For example, the SoC/IC- level wireless components cannot be pre-certified be-cause they do not have a fixed RF path and antenna. Customers therefore must conduct the full set of radio tests to certify their product. The test tools referenced in section 4 Embedded Software Tools should be used to validate the RF performance of the device. For more information on RF Regulatory requirements for various regions, refer to AN1048: Regulatory RF Module Certifications.

Range Test
A crucial aspect of designing an RF wireless product is maximizing its operational range when communicating with another device. To achieve this, perform a range test, which could be the final but important step for characterizing the product. The test setup consists of a transmitter and a receiver with their known RF parameters (transmit power, receiver sensitivity) and their spatial arrangement. Wireless communication is then initiated (frequency, data rate, and modulation parameters chosen according to the desired operation), and the receiver performance is measured.

The accounting of the measurable parameters and environmental effects is called the link budget, according to the following equation:

X = X + X − X − S − + X − X

where:

• PRX: received power (dBm)
• PTX: transmitter output power (dBm)
• GTX: transmitter antenna gain (dBi)
• LTX: transmitter losses (cables, connectors) (dB)
• LFS: path loss (free space and multipath propagation) (dB)
• LM: miscellaneous losses (fading, polarization, mismatch, interference, absorption, weather) (dB)
• GRX: receiver antenna gain (dBi)
• LRX: receiver losses (cables, connectors) (dB)

However, other variables play a crucial role in the quality of the RF link, such as:

• Antenna radiation pattern: Silicon Labs recommends placing the transmitter and receiver devices facing each another with their max-imas of radiation.
• Frequency offset: Any occurrent frequency offset between the transmitter and receiver can degrade the range.
• Distance from the ground: The proximity of ground degrades performance. See KBA RF range factors for a list of the most prominent effecting variables.

Prior to the range test, ensure that the product is finalized in terms of overall RF performance (TX power, harmonics, RX sensitivity, antenna matching) and that the test procedure best represents a use case scenario with the inclusion of the plastic case or having a human hand in the proximity of the device (if there is going to be one). Sensitivity is the minimum received power at the antenna port of the device at which the data transfer is still adequately successful. A common way of determining sensitivity is by counting the number of sent, and successfully received packets, and calculating the Packet Error Rate percentage (PER%). A similar method is calculating the Bit Error Rate percentage (BER%). Refer to the datasheet of the Silicon Labs device for the ideal sensitivity values depending on data rate, frequency, and modulation. Silicon Labs recommends first choosing an open field with as few environmental factors as possible to determine the maximum range. Then, measure the BER or PER and modify the range accordingly, so that the measured value is equal to or less than the predefined value in the datasheet of the device. If equal, the received signal strength at the antenna port equals the sensitivity of the device by definition.

It is good practice to choose an operating range that is smaller than the determined maximum range so that there is some margin (link margin) between the received signal and the sensitivity of the device to allow for the detrimental effects of the degrading variables. After the range of the communication has been determined, any introduced additional link budget to the system (e.g., by increasing the transmitter power) also yields an improvement in the range of the RF link, which can be approximated by the following formula:

where:

• ΔLB is the extra link budget introduced to the RF link
• n is the propagation factor, which is usually between 2.8 and 4 (3 for line of sight) outdoors
• Roriginal is the range prior to the introduced link budget
• Rnew is the improved range after the introduced link budget
• ΔR is the ratio of the new range to the original range
• As an example, this means that if the link budget introduced to the RF link is e.g., 3 dB and n = 3 is assumed, the calculated range increase is ΔR = 1.25 (25% improvement). Follow UG471: Flex SDK v3.x Range Test Demo User’s Guide for the range test evaluation of the Gecko EFR32 devices.

Revision History

Revision 0.8
Added Chapter 6, Range Test.
Revision 0.7
Deleted obsolete references to AN700.0: Manufacturing Test Guidelines for the EM35x.
Revision 0.6
Added Silicon Labs OpenThread to Table 4.1 and updated document cross references.
Revision 0.5
Content updated and reorganized in conjunction with the conversion of the old AN700: Manufacturing Test Guidelines for the Ember EM35x into AN700.0: Manufacturing Test Guidelines for the EM35x and AN700.1: Manufacturing Test Guidelines for the EFR32, as well as the introduction of AN1162: Using the Manufacturing Test Library for EmberZNet.

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 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 use of a Silicon Labs product in such unauthorized applications.

Note : This content may contain offensive terminology that is now obsolete. Silicon Labs is replacing these terms with inclusive language wherever possible. For more
information, visit www.silabs.com/about-us/inclusive-lexicon- project

Trademark Information

Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, “the world’s most energy friendly microcontrollers”, Redpine Signals®, WiSeConnect , n-Link, ThreadArch®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio®, 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
www.silabs.com

Documents / Resources

| SILICON LABS AN718 PCB Resources - v5.5.0 - Simplicity Studio 5 [pdf] Instructions
AN718 PCB Resources - v5.5.0 - Simplicity Studio 5, AN718, PCB Resources - v5.5.0 - Simplicity Studio 5, Simplicity Studio 5, Studio 5
---|---

References

• Silicon Labs
• Silicon Labs
• About Us - Silicon Labs
• Silicon Labs Community
• Internet of Things (IoT) - Silicon Labs
• Simplicity Studio - Silicon Labs

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>