2011-05-18 03:57:18 +03:00
|
|
|
<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
|
2011-05-18 13:23:11 +03:00
|
|
|
SMT line, and testing and conditioning of the components prior to
|
|
|
|
|
soldering.
|
2011-05-18 03:57:18 +03:00
|
|
|
</DL>
|
|
|
|
|
|
|
|
|
|
|
2011-05-18 19:53:01 +03:00
|
|
|
<H2>Setup</H2>
|
2011-05-18 03:57:18 +03:00
|
|
|
|
|
|
|
|
<H3>PC software installation</H3>
|
2011-05-18 19:34:26 +03:00
|
|
|
<H3>Ben software installation</H3>
|
2011-05-18 19:53:01 +03:00
|
|
|
<H3>Ben software setup</H3>
|
2011-05-18 03:57:18 +03:00
|
|
|
<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>
|
|
|
|
|
|
2011-05-18 13:23:11 +03:00
|
|
|
<H3>Component placement and orientation</H3>
|
|
|
|
|
|
|
|
|
|
<H3>Supply voltages</H3>
|
|
|
|
|
|
2011-05-18 03:57:18 +03:00
|
|
|
<H3>Clock frequency</H3>
|
|
|
|
|
|
2011-05-18 13:23:11 +03:00
|
|
|
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>
|
|
|
|
|
|
2011-05-18 03:57:18 +03:00
|
|
|
<P>
|
|
|
|
|
<HR>
|
2011-05-18 13:23:11 +03:00
|
|
|
Last update: 2011-05-18 <I>Werner Almesberger</I>
|
2011-05-18 03:57:18 +03:00
|
|
|
<HR>
|
|
|
|
|
</BODY>
|
|
|
|
|
</HTML>
|
