Hardware design verification

Članak
02/09/2022
8 min. za čitanje

This topic describes ways to validate the hardware features of your Azure Sphere-based device, such as a board or module. Use this information as a guide in devising a range of high-level manual tests that will help verify your design.

These testing guidelines resulted from Microsoft's internal process for verifying the functionality of the MT3620 reference board design. You can use the techniques for other products based on the MT3620 chip, although some of the tests may require modification and customization to validate the features of your particular hardware.

For information about factory-floor testing, see Manufacturing connected devices.

Note the following general requirements and recommendations when performing the tests described in this document:

The Device Under Test (DUT) should be connected via USB to a host PC that has the latest Azure Sphere SDK installed. In addition, it is assumed the host PC has the latest version of Visual Studio or Visual Studio Code installed.
Some of the tests require the Azure Sphere CLI, which is installed as part of the Azure Sphere SDK.
Many of the tests use the existing MT3620 sample applications published on GitHub. These samples can be used as a starting point for creating more in-depth test applications, customized to your particular requirements.
We recommend testing every interface that your board or module exposes. This document assumes all MT3620 interface signals are exposed, so you'll need to adapt some of the tests to match the number and types of interfaces that the DUT exposes.

Support interfaces

The MT3620 provides three UART support interfaces, although only two of these are available for general use. In addition, it provides an SWD interface. To provide compatibility with the Azure Sphere development tooling, these interfaces must connect to the host PC through a 4-port, UART-to-USB interface chip. See the MCU programming and debugging interface for details about the design of such an interface—the current MT3620 reference board design uses an FTDI FT4232HQ UART-to-USB interface chip.

To test the support interfaces:

Attach the DUT to the host PC.
Open Device Manager on the host PC and check that three USB Serial Converters are listed under Universal Serial Bus controllers. They should be labeled A, C, and D.

This test confirms that the host PC has correctly recognized the UART-to-USB interface. Service UART, Recovery UART, and SWD interface provide additional detail to help you verify the correct operation of both the UART-to-USB interface and the support interfaces exposed by the DUT.

Service UART

The service UART provides the main interface between the MT3620 and the development environment running on a host PC.

To test the service UART:

Attach the DUT to the host PC.
Run the following command to get information about the device:
```
azsphere device show-attached
```

This command should return basic information about the attached device.

Recovery UART

The recovery UART provides a means of re-flashing, or recovering, the MT3620 to the latest version of the Azure Sphere operating system.

To test the recovery UART:

Attach the DUT to the host PC.
Attempt to recover the board using the following command:
```
azsphere device recover
```

SWD interface

The SWD interface is used for programming the real-time M4F cores. The UART-to-USB interface serves as the SWD probe, thereby avoiding the need to use a separate hardware SWD programmer. The Azure Sphere SDK uses OpenOCD software to provide on-chip debugging over SWD.

To test the SWD interface:

Attach the DUT to the host PC.
Open the HelloWorld_RTApp_MT3620_BareMetal sample application in Visual Studio and attempt to deploy and debug the application.

Power supplies

The MT360 should be powered from a 3.3V power supply.

In addition, the MT3620's internal real-time clock (RTC) can be powered either from the main 3.3V power supply or from a separate supply derived, for example, from a battery (coin cell). If the RTC is not powered, the chip will fail to boot correctly.

Main 3.3V power supply

Check that the voltage of the main power supply is the expected 3.3V. In addition, check for excessive ripple and noise on the supply lines. For MT3620 electrical characteristics and other relevant information, see the MT3620 datasheet from MediaTek.

RTC power supply

With the DUT powered from a 3.3V supply, connect a separate 3.3V supply (or battery) to the RTC supply line.
Use the Powerdown sample application to place the DUT into low power mode. The main power supply current consumption should drop, indicating the chip has entered low-power mode.

Information about Power Down mode for the MT3620 and associated control signals can be found in the MT3620 reference development board (RDB) user guide and the MT3620 hardware notes.

Wi-Fi

Wi-Fi parameters such as the SSID of the networks to which the device can connect are set up by using the azsphere device wifi command in the Azure Sphere CLI.

Test connection to an access point

To test Wi-Fi connection to an access point:

Try to connect to a known Wi-Fi access point (AP):

azsphere device wifi add --ssid <wifi-ssid> --psk <wifi-password>

Wait 5-10 seconds and enter the following command to check your Wi-Fi connection:
```
azsphere device wifi show-status
```

You should see that the device is connected to the Wi-Fi network you specified, that the configuration is enabled, and the state is connected. See azsphere device wifi if you need more information.

Test Wi-Fi data transfer

To test Wi-Fi data transfer, use the HTTPS_Curl_Easy sample application to connect to an endpoint and download a web page.

In addition, you can test network bandwidth using iPerf3. The Manufacturing Samples package contains a sample iPerf3 client implemented as an Azure Sphere app. If you need this package, contact your Microsoft representative.

Test low-level RF features

For information on testing low-level radio frequency (RF) operation, see RF Test Tools.

Peripherals

The following sections describe ways to test the various peripherals on the device.

GPIO

The MT3620 provides many GPIOs, which are multiplexed with other interfaces. You can configure the GPIOs as either inputs or outputs.

The high-level GPIO sample application provides a simple way to test GPIO input and output functionality.

To create an automated test for multiple GPIOs, you can use a loopback approach. This approach is particularly appropriate for GPIOs because it uses the DUT to test itself and requires minimal additional test equipment.

For example, connect GPIO0 to GPIO1, and write code that configures one of the GPIOs as an input and the other as an output. The application then toggles the state of the output GPIO while monitoring the state of the input GPIO.

Then, using the same loopback setup, reconfigure the output GPIO as an input and the input GPIO as an output, and then rerun the test. In this way, both GPIOs are tested in input and output mode. Extend this approach to test all exposed GPIOs.

UART

The MT3620 provides up to five UART interfaces, which are multiplexed with other interfaces.

To test basic UART functionality, use the high-level UART sample application. The sample connects the RXD and TXD pins of the same UART, thereby creating a loopback. In this case, any data that is written to the TXD pin will be read back by the RXD pin. Note that the sample application does not use flow control.

I2C

The MT3620 provides up to five I2C interfaces, which are multiplexed with other interfaces

To test I2C, use the high-level I2C accelerometer sample application.

Connect an LSM6DS3 accelerometer chip to one of the DUT's I2C interfaces. When the sample is run, it first interrogates the accelerometer's WHO_AM_I register and then repeatedly reads the x-axis acceleration. Depending on the orientation of the accelerometer, the x-axis reading should vary between +1g and -1g. Repeat this test for each of the I2C interfaces.

SPI

The MT3620 provides up to five SPI interfaces, which are multiplexed with other interfaces.

To test SPI, use the high-level SPI accelerometer sample application.

Connect an LSM6DS3 accelerometer chip to one of the DUT's SPI interfaces. When the sample is run, it first interrogates the accelerometer's WHO_AM_I register and then repeatedly reads the x-axis acceleration. Depending on the orientation of the accelerometer, the x-axis reading should vary between +1g and -1g.

ADC

The MT3620 provides up to eight analog ADC inputs.

To test ADC, use the high-level ADC sample application to read an analog voltage measured by one of the DUT's ADC channels, while applying a known voltage to the ADC input.

You could create a more advanced test around an I2C digital-to-analog converter (DAC), such as an Analog Devices LTC2635, as follows:

Connect the I2C interface on the DAC to one of the DUT's I2C interfaces.
Connect the analog outputs from the DAC to one of the ADC inputs on the DUT.
Write test code to control the analog output voltage level from each of the DAC channels, and to read the corresponding ADC input levels.
Check that the voltage read by the ADC corresponds to the voltage being output by the DAC.

PWM

The MT3620 provides up to eight PWM-capable outputs.

To test PWM, use the high-level PWM sample application to output a PWM signal. Monitor the PWM output on an oscilloscope to verify the duty cycle and frequency are as expected.

Alternatively, connect one of the PWM outputs to a different GPIO that is configured as an input. Write test code that runs on one of the real-time M4 cores, reads the state of the input pin, and times high-low transitions. Calculate the duty cycle and frequency from the generated data and compare with the PWM parameters. This test must be done on an M4 core because the real-time operation of the M4 core can record the timing of pin state changes with higher accuracy than the A7.

I2S

The MT3620 provides two separate I2S digital audio interfaces.

Currently, I2S is supported only on the real-time cores. You can test by using sample applications and drivers from MediaTek and CodeThink.