mirror of
git://projects.qi-hardware.com/ben-wpan.git
synced 2024-11-17 23:40:38 +02:00
90ee726285
- setup.hmac, test.hmac: it's no longer necessary to "type into the window" (i.e., with the focus there)
248 lines
8.6 KiB
Plaintext
248 lines
8.6 KiB
Plaintext
<!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>
|