mirror of
git://projects.qi-hardware.com/ben-wpan.git
synced 2024-11-23 07:23:09 +02:00
43f179d6d8
- include/daemon.h (daemonize), lib/daemon.c: shed all ties with the process' previous surroundings - lib/Makefile (OBJS): added daemon.o
293 lines
8.3 KiB
HTML
293 lines
8.3 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 software setup</H3>
|
|
|
|
This needs to be done each time the Ben is booted.
|
|
|
|
<H4>Enable network access</H4>
|
|
<H4>Silence other 8:10 card users</H4>
|
|
|
|
|
|
<!-- ---------------------------------------------------------------------- -->
|
|
|
|
|
|
<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 <I>Werner Almesberger</I>
|
|
<HR>
|
|
</BODY>
|
|
</HTML>
|