<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<TITLE>Production and testing: Functional test</TITLE>
<BODY bgcolor="#ffffff" link="#000000" vlink="#404040">

<INCLUDE file="style.inc">

<PAGE_BAR title="Production and testing">
  <PAGE_ITEM href="setup.html">Software setup</PAGE_ITEM>
  <PAGE_ITEM href="flash.html">Flashing</PAGE_ITEM>
  <PAGE_CURR href="test.html">Functional test</PAGE_CURR>
  <PAGE_ITEM href="analysis.html">Fault analysis</PAGE_ITEM>
</PAGE_BAR>

<SECTION_BAR>
  <SECTION_ITEM href="#atben">atben setup</SECTION_ITEM>
  <SECTION_ITEM href="#atusb">atusb setup</SECTION_ITEM>
  <SECTION_ITEM href="#procedure">Test procedure</SECTION_ITEM>
</SECTION_BAR>


<!-- ====================================================================== -->


<SECTION ref="atben" title="Test setup for atben">

To test an <B>atben</B> board, place a reference <B>atusb</B> board into
the PC, insert the <B>atben</B> board into the Ben, and place both devices
at the same location and with the same orientation used when acquiring the
signal strength profile.
<P>
The two devices should be about 1 m apart. Their vicinity should be free
from obstructions and items that can reflect or absorb RF signals. Such
items include metal chairs and human bodies.
Location and orientation should
be easily reproducible, e.g., by marking the device's edges on the table
with tape. Other transmitters in the 2.4 GHz band will interfere with
measurements and should be kept as far away and as inactive as possible.
<P>
<IMG src="setup-A.png">
<P>


<!-- ====================================================================== -->


<SECTION ref="atusb" title="Test setup for atusb">

The test setup is the same as for <B>atben</B> testing, except that the
DUT and reference device roles are reversed.
<P>
<IMG src="setup-B.png">
<P>


<!-- ====================================================================== -->


<SECTION ref="procedure" title="Test procedure">

The test process is started from the directory <SAMP>ben-wpan/prod/</SAMP>
with
<PRE>
make ben
</PRE>
for an <B>atben</B> DUT and with
<PRE>
make usb
</PRE>
for an <B>atusb</B> DUT. It performs the following steps:
<UL>
  <LI>Enumeration (<B>atusb</B> only)
  <LI>LED (<B>atusb</B> only)
  <LI>GPIO scan
  <LI>Identification
  <LI>Crystal frequency
  <LI>Spectrum
  <LI>Receive
  <LI>Send
</UL>

Of these tests, only "LED" and "Spectrum" require operator input. The
other tests run without interaction.
<P>
The test scripts log the commands they execute and their output in the
file <SAMP>_log</SAMP>.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="Enumeration (atusb only)">

The enumeration test verifies that the <B>atusb</B> board has been
identified by the PC's USB stack. If this test fails, the board may
not be plugged in correctly or it may be missing the firmware. A
board that has passed both stages of the firmware flashing process
should always pass the enumeration test.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="LED (atusb only)">

In the LED test, the <B>atusb</B> LED blinks quickly until the operator
decides whether it is working properly.
To finish the test, the operator must type either <B>P</B> to pass, or
<B>F</B>, or <B>Q</B> to fail.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="GPIO scan">

The GPIO scan outputs a series of test patterns on the I/O lines driving
the transceiver and compares the state at which the lines settle with a
set of expected values. This allows the detection of unconnected pins
and of shorted traces.
<P>
If the GPIO scan encounters an inconsistency, it fails the test and writes
a report to the
file <SAMP>_log</SAMP>. This report contains a list of GPIO pins with their
configuration, the expected value, and their actual value.
<P>
For example, a short between SLP_TR and VDD on an <B>atben</B> board would
be reported as follows:
<PRE>
name    cfg exp got
SCLK    Z   -   1
MISO    Z   -   1
SLP_TR  Z   0   1       ***
MOSI    Z   -   1
nSEL    Z   1   1
IRQ     Z   0   0
at "zzozho", next "# reset state"
</PRE>
The configuration is <B>0</B> for a pin driven low, <B>1</B> for a pin driven
high, <B>Z</B> for a pin in Hi-Z state, and <B>R</B> for Hi-Z state with a
pull-up.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="Identification">

This test reads the transceiver's registers that contain values identifying
the manufacturer, the chip's part number, and the chip revision. If an
<B>atusb</B> board fails this test, this probably means that the MISO signal
between transceiver and the microcontroller has a problem.
<P>
On <B>atben</B>, failure may simply indicate an improperly
inserted board. Eject the board, re-insert, and try again. If the test
keeps on failing, this may indicate a problem with MOSI, MISO, nSEL,
SCLK, the power supply, the crystal oscillator, or possibly the position
of the transceiver chip.
<P>
Note: this test is meant as a higher level test. The GPIO test should
eventually provide more detailed results for problems with the SPI interface.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="Crystal frequency">

This test measures the frequency of the crystal oscillator in the DUT.
On <B>atben</B>, it does this by transmitting packets, and measuring
the time between the SLP_TR pulse that starts the transmission and the
interrupt signaling the end of the transmission.
On <B>atusb</B>, the microcontroller counts the clock cycles and the
number of cycles is compared with the PC's NTP-disciplined clock.
<P>
If this test fails, this may indicate that the load capacitors of the
crystal are missing, badly soldered, or have the wrong value. It could
also mean that the crystal itself is defective. Another possible cause
of oscillator malfunction could be flux residues bridging traces.
<P>
The <A href="fault.html">fault analysis page</A> has more details on
testing the crystal oscillator.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="Spectrum">

The spectrum test measures the reception of a signal sent from the
reference device to the DUT. It does this across the entire frequency
range in which the WPAN boards operate, allowing the detection of
frequency-dependent anomalies.
<P>
This test depends on numerous external factors, like the exact position
and orientation of the two devices with respect to each other, and the
presence of obstacles and conductive items (metal, people, etc.).
Because of the test's sensitivity
to environmental factors, the operator needs to decide when the result
represents a valid measurement and then confirm the result shown.
<P>
The image below shows the typical display during the spectrum test:
the white line is the measured signal strength. The red lines indicate
the minimum and maximum allowed values. The green circle in the upper
right corner indicates that the signal strength is within the limits.
A downward-pointing red triangle would indicate that the signal is too
weak, an upward-pointing yellow triangle would indicate that the signal
is too strong.
<P>
<A href="atrf-path.png"><IMG src="atrf-path-small.png"></A>
<P>
To finish the test, the operator must type either <B>P</B>, <B>F</B>,
or <B>Q</B>. <B>P</B> means "pass" and can only be
entered if the measurement is within the limits. <B>F</B> means "fail"
and can only be entered if the measurements is outside the limits.
<B>Q</B>, quit, can be entered at any time and also fails the test.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="Receive">

In the receive test, the reference device sends a number of frames to the
DUT. The test program verifies correct reception of all the frames. A
device that has passed all the preceding tests should not encounter
problems in the receive test. If it does, there may be a problem with
the bypassing of the transceiver's 1.8 V supplies.


<!-- ---------------------------------------------------------------------- -->


<SUBSECTION title="Send">

The send test is like the receive test, but with the DUT acting as the
sender and the reference acting as the receiver. If a device passes the
receive test but fails the send test, there is probably an issue with
the bypass capacitors of the analog 1.8 V supply.
<P>
Another possible cause could a problem with the SLP_TR signal. The
GPIO test should eventually catch this issue, but it may currently
remain undetected until the send test.

<END author="Werner Almesberger" date="<GEN_DATE>">
</BODY>
</HTML>
