1
0
mirror of git://projects.qi-hardware.com/ben-wpan.git synced 2024-11-09 09:31:32 +02:00
ben-wpan/prod/doc/index.html

333 lines
9.4 KiB
HTML

<TITLE>Production and testing</TITLE>
<BODY>
<HTML>
<H1>Production and testing</H1>
This document gives a high-level description of the production test process
for <B>atben</B> and <B>atusb</B> boards, plus - in the case of <B>atusb</B>
the production steps required between the boards leaving the SMT line and the
actual testing.
<P>
The testing serves two purposes:
<OL>
<LI>Ascertain the correctness of the preceding production steps, and
<LI>identify suffering from random production flaws and either discard
them or prepare them for repair.
</OL>
The results of testing and fault analysis also provide feedback for the
SMT process and steps preceding it.
<P>
The following diagram illustrates the workflow:
<P>
<IMG src="flow.png">
<P>
Only <B>atusb</B> boards contain firmware and need flashing (which is
a two-step process, see below). The functional tests and further fault
analysis are largely the same for <B>atben</B> and <B>atusb</B>.
<P>
Devices accepted for further use can then be packaged for shipping.
Defective devices can be discarded or retained for a deeper analysis.
<!-- ====================================================================== -->
<H2>Terminology</H2>
<DL>
<DT>Ben</DT>
<DD>a device capable of hosting the <B>atben</B> and <B>atusb-pgm</B>
boards. In the production process, a Ben can perform three different
roles:
<OL>
<LI> Host an <B>atben</B> board acting as DUT
<LI> Host an <B>atben</B> board acting as reference
<LI> Host an <B>atusb-pgm</B> used for flashing the boot loader
</OL>
In this document, we assume that a single Ben is used in all
three roles, with the board in its 8:10 card slot changed as
the role requires.
<DT>PC</DT>
<DD>a device capable of connecting to a Ben via USB, and of hosting an
<B>atusb</B> board. In the production process, a PC can perform three
different roles:
<OL>
<LI> Host an <B>atusb</B> board acting as DUT
<LI> Host an <B>atusb</B> board acting as reference
<LI> Control a Ben via USB (for convenience)
</OL>
In this document, we assume that a single PC is used in all
three roles, with one USB host port permanently connecting to the
Ben, and a second USB host port populated with <B>atusb</B> boards
as needed.
<DT>DUT</DT>
<DD>Device Under Test. An <B>atben</B> or <B>atusb</B> board that
has left SMT, and is being prepared for testing or in the process
of being tested.
<DT>Reference</DT>
<DD>An <B>atben</B> or <B>atusb</B> device that is known to work and
and that acts as a peer for RF communication with the DUT.
<DT>SMT</DT>
<DD>In this context, the actual process of soldering components to
the unpopulated PCB, and all related tasks providing an input to
this process. Such related tasks include the configuration of the
SMT line, and testing and conditioning of the components prior to
soldering.
</DL>
<!-- ====================================================================== -->
<H2>Software setup</H2>
Before performing any production tests, various pieces of software
need to be installed on Ben and PC, and configuration settings
@@@
<!-- ---------------------------------------------------------------------- -->
<H3>PC software installation</H3>
@@@
<H4>Install ben-wpan tools</H4>
@@@
<H4>Register Ben host name</H4>
To simplify accessing the Ben via TCP/IP, its IP address should be
registered in the hosts file on the PC. If the Ben is running OpenWrt,
use the following command:
<PRE>
echo 192.168.254.101 ben >>/etc/hosts
</PRE>
<P>
If the Ben is running Jlime, the address would be as follows:
<PRE>
echo 192.168.1.202 ben >>/etc/hosts
</PRE>
<P>
If using the same PC with Bens running OpenWrt and Jlime, one may choose
different host names depending on the distribution, and adapt the commands
used in the production and testing process accordingly. For example,
<PRE>
echo 192.168.254.101 ben >>/etc/hosts
echo 192.168.1.202 jlime >>/etc/hosts
</PRE>
<!-- ---------------------------------------------------------------------- -->
<H3>Ben system setup</H3>
The configuration setting described in this section are lost on each
reset or reboot and either need to be entered again or a setup script
running at boot time has to
This needs to be done each time the Ben is booted.
<H4>Enable network access</H4>
Once the Ben has booted and started USB networking, the interface
on the PC side is configured as follows:
<PRE>
ifconfig usb0 192.168.254.100 up
</PRE>
<P>
These are the settings for OpenWrt, assuming the network device is
called "usb0". If using Jlime, the command would be as follows:
<PRE>
ifconfig usb0 192.168.1.200 up
</PRE>
<H4>Silence other 8:10 card users</H4>
Before running any of the ben-wpan utilities, other users of the 8:10
card slot have to be disabled. In a Ben running the regular OpenWrt or
Jlime distribution, the only such user that is automatically started
is the MMC kernel driver. The following command disables it:
<PRE>
echo jz4740-mmc.0 >/sys/bus/platform/drivers/jz4740-mmc/unbind
</PRE>
<P>
If a WPAN-enabled kernel has been installed, the AT86RF230 driver takes
the place of the MMC driver. To disable it, run
<PRE>
echo spi2.0 >/sys/bus/spi/drivers/at86rf230/unbind
</PRE>
<H4>Start atrf-proxy</H4>
On the Ben, launch the proxy daemon. We pass the option -b to background it:
<PRE>
atrf-proxy -b
</PRE>
<!-- ---------------------------------------------------------------------- -->
<H3>Ben software installation</H3>
<H4>Password-less remote access</H4>
To enable password-less remote access from the PC, setup to betwork
access to the Ben and run the following command:
<PRE>
ssh ben 'cat >>/etc/dropbear/authorized_keys' <~/.ssh/id_rsa.pub
</PRE>
<!-- ---------------------------------------------------------------------- -->
<H3>Test profiles</H3>
<!-- ====================================================================== -->
<H2>Flashing (atusb only)<H2>
<!-- ---------------------------------------------------------------------- -->
<H3>Flashing the boot loader</H3>
<P>
<IMG src="setup-C.png">
<P>
<!-- ---------------------------------------------------------------------- -->
<H3>Flashing the application</H3>
<P>
<IMG src="setup-D.png">
<P>
<!-- ====================================================================== -->
<H2>Functional test</H2>
<!-- ---------------------------------------------------------------------- -->
<H3>Test setup for atben</H3>
<P>
<IMG src="setup-A.png">
<P>
<!-- ---------------------------------------------------------------------- -->
<H3>Test setup for atusb</H3>
<P>
<IMG src="setup-B.png">
<P>
<!-- ---------------------------------------------------------------------- -->
<H3>Test procedure</H3>
<!-- ====================================================================== -->
<H2>Fault analysis</H2>
<!-- ---------------------------------------------------------------------- -->
<H3>Component placement and orientation</H3>
<!-- ---------------------------------------------------------------------- -->
<H3>Supply voltages</H3>
<!-- ---------------------------------------------------------------------- -->
<H3>Clock frequency</H3>
The flawless performance of the crystal oscillator is crucial for
operation. Anomalies are easy to detect with even a low-cost oscilloscope
and pinpoint specific problems and help to select further analysis steps.
<P>
The crystal used in <B>atben</B> and <B>atusb</B> has a nominal tolerance
of +/- 15 ppm at 22-28 C. Low-cost oscilloscopes typically have a timing
accuracy of
+/- 100 ppm, which means that only major excursions can be detected by
measuring the clock output with such an instrument. Full-speed USB only
requires an accuracy of +/- 2500 ppm.
We can therefore consider all results within a range of +/- 1000 ppm as
sufficient, and perform more precise measurements by other means. This
applies to <B>atben</B> as well as to <B>atusb</B>.
<P>
<H4>Measuring the clock on atben</H4>
<B>atben</B> normally does not output a clock signal. A 1 MHz clock
can be enabled with the following command:
<PRE>
atrf-txrx -d net:ben -C 1
</PRE>
This configures <B>atben</B> as a promiscuous receiver. The reception
of any IEEE 802.15.4 frame or pressing Ctrl-C will terminate the command.
<P>
<TABLE>
<TR><TH align="left">Clock<TH align="left">Action
<TR><TD>0 Hz<TD>Check voltages; check that the clock is enabled;
check for shorts around crystal; check connectivity of crystal
<TR><TD>0.999-1.001 MHz, ~3.3 Vpp<TD>Perform precision measurement with
<B>atrf-xtal</B>
<TR><TD>Other<TD>Check voltages; check for contamination around crystal
</TABLE>
<P>
<H4>Measuring the clock on atusb</H4>
The transceiver provides the clock for the microcontroller in <B>atusb</B>.
A clock signal is therefore always available. Immediately after reset,
the transceiver generates a 1 MHz clock. When the microcontrolled comes out
of reset, it raises the transceiver's clock output to 8 MHz and then
enables USB.
<P>
<TABLE>
<TR><TH align="left">Clock<TH align="left">Action
<TR><TD>0 Hz<TD>Check voltages; check for shorts around crystal; check
connectivity of crystal
<TR><TD>0.999-1.001 MHz, ~3.3 Vpp<TD>Check presence of firmware; check for
shorts on SPI signals; check connectivity of SPI signals
<TR><TD>7.992-8.008 MHz, ~3.3 Vpp<TD>Perform precision measurement with
<B>atrf-xtal</B>
<TR><TD>Other<TD>Check voltages; check for contamination around crystal
</TABLE>
<H4>Precision measurements</H4>
<P>
<HR>
Last update: 2011-05-18&nbsp;&nbsp;<I>Werner Almesberger</I>
<HR>
</BODY>
</HTML>