IEEE 802.15.4 subsystem
Sign in or create your account | Project List | Help
IEEE 802.15.4 subsystem Git Source Tree
Root/
Source at commit 90ee7262853cfdfb12015801c977093645928bf4 created 12 years 9 months ago. By Werner Almesberger, prod/doc/: atrf-path now accepts keypresses from all the usual places | |
---|---|
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
2 | <HTML> |
3 | <TITLE>Production and testing: Functional test</TITLE> |
4 | <BODY bgcolor="#ffffff" link="#000000" vlink="#404040"> |
5 | |
6 | <INCLUDE file="style.inc"> |
7 | |
8 | <PAGE_BAR title="Production and testing"> |
9 | <PAGE_ITEM href="setup.html">Software setup</PAGE_ITEM> |
10 | <PAGE_ITEM href="flash.html">Flashing</PAGE_ITEM> |
11 | <PAGE_CURR href="test.html">Functional test</PAGE_CURR> |
12 | <PAGE_ITEM href="analysis.html">Fault analysis</PAGE_ITEM> |
13 | </PAGE_BAR> |
14 | |
15 | <SECTION_BAR> |
16 | <SECTION_ITEM href="#atben">atben setup</SECTION_ITEM> |
17 | <SECTION_ITEM href="#atusb">atusb setup</SECTION_ITEM> |
18 | <SECTION_ITEM href="#procedure">Test procedure</SECTION_ITEM> |
19 | </SECTION_BAR> |
20 | |
21 | |
22 | <!-- ====================================================================== --> |
23 | |
24 | |
25 | <SECTION ref="atben" title="Test setup for atben"> |
26 | |
27 | To test an <B>atben</B> board, place a reference <B>atusb</B> board into |
28 | the PC, insert the <B>atben</B> board into the Ben, and place both devices |
29 | at the same location and with the same orientation used when acquiring the |
30 | signal strength profile. |
31 | <P> |
32 | The two devices should be about 1 m apart. Their vicinity should be free |
33 | from obstructions and items that can reflect or absorb RF signals. Such |
34 | items include metal chairs and human bodies. |
35 | Location and orientation should |
36 | be easily reproducible, e.g., by marking the device's edges on the table |
37 | with tape. Other transmitters in the 2.4 GHz band will interfere with |
38 | measurements and should be kept as far away and as inactive as possible. |
39 | <P> |
40 | <IMG src="setup-A.png"> |
41 | <P> |
42 | |
43 | |
44 | <!-- ====================================================================== --> |
45 | |
46 | |
47 | <SECTION ref="atusb" title="Test setup for atusb"> |
48 | |
49 | The test setup is the same as for <B>atben</B> testing, except that the |
50 | DUT and reference device roles are reversed. |
51 | <P> |
52 | <IMG src="setup-B.png"> |
53 | <P> |
54 | |
55 | |
56 | <!-- ====================================================================== --> |
57 | |
58 | |
59 | <SECTION ref="procedure" title="Test procedure"> |
60 | |
61 | The test process is started from the directory <SAMP>ben-wpan/prod/</SAMP> |
62 | with |
63 | <PRE> |
64 | make ben |
65 | </PRE> |
66 | for an <B>atben</B> DUT and with |
67 | <PRE> |
68 | make usb |
69 | </PRE> |
70 | for an <B>atusb</B> DUT. It performs the following steps: |
71 | <UL> |
72 | <LI>Enumeration (<B>atusb</B> only) |
73 | <LI>LED (<B>atusb</B> only) |
74 | <LI>GPIO scan |
75 | <LI>Identification |
76 | <LI>Crystal frequency |
77 | <LI>Spectrum |
78 | <LI>Receive |
79 | <LI>Send |
80 | </UL> |
81 | |
82 | Of these tests, only "LED" and "Spectrum" require operator input. The |
83 | other tests run without interaction. |
84 | <P> |
85 | The test scripts log the commands they execute and their output in the |
86 | file <SAMP>_log</SAMP>. |
87 | |
88 | |
89 | <!-- ---------------------------------------------------------------------- --> |
90 | |
91 | |
92 | <SUBSECTION title="Enumeration (atusb only)"> |
93 | |
94 | The enumeration test verifies that the <B>atusb</B> board has been |
95 | identified by the PC's USB stack. If this test fails, the board may |
96 | not be plugged in correctly or it may be missing the firmware. A |
97 | board that has passed both stages of the firmware flashing process |
98 | should always pass the enumeration test. |
99 | |
100 | |
101 | <!-- ---------------------------------------------------------------------- --> |
102 | |
103 | |
104 | <SUBSECTION title="LED (atusb only)"> |
105 | |
106 | In the LED test, the <B>atusb</B> LED blinks quickly until the operator |
107 | decides whether it is working properly. |
108 | To finish the test, the operator must type either <B>P</B> to pass, or |
109 | <B>F</B>, or <B>Q</B> to fail. |
110 | |
111 | |
112 | <!-- ---------------------------------------------------------------------- --> |
113 | |
114 | |
115 | <SUBSECTION title="GPIO scan"> |
116 | |
117 | The GPIO scan outputs a series of test patterns on the I/O lines driving |
118 | the transceiver and compares the state at which the lines settle with a |
119 | set of expected values. This allows the detection of unconnected pins |
120 | and of shorted traces. |
121 | <P> |
122 | If the GPIO scan encounters an inconsistency, it fails the test and writes |
123 | a report to the |
124 | file <SAMP>_log</SAMP>. This report contains a list of GPIO pins with their |
125 | configuration, the expected value, and their actual value. |
126 | <P> |
127 | For example, a short between SLP_TR and VDD on an <B>atben</B> board would |
128 | be reported as follows: |
129 | <PRE> |
130 | name cfg exp got |
131 | SCLK Z - 1 |
132 | MISO Z - 1 |
133 | SLP_TR Z 0 1 *** |
134 | MOSI Z - 1 |
135 | nSEL Z 1 1 |
136 | IRQ Z 0 0 |
137 | at "zzozho", next "# reset state" |
138 | </PRE> |
139 | The configuration is <B>0</B> for a pin driven low, <B>1</B> for a pin driven |
140 | high, <B>Z</B> for a pin in Hi-Z state, and <B>R</B> for Hi-Z state with a |
141 | pull-up. |
142 | |
143 | |
144 | <!-- ---------------------------------------------------------------------- --> |
145 | |
146 | |
147 | <SUBSECTION title="Identification"> |
148 | |
149 | This test reads the transceiver's registers that contain values identifying |
150 | the manufacturer, the chip's part number, and the chip revision. If an |
151 | <B>atusb</B> board fails this test, this probably means that the MISO signal |
152 | between transceiver and the microcontroller has a problem. |
153 | <P> |
154 | On <B>atben</B>, failure may simply indicate an improperly |
155 | inserted board. Eject the board, re-insert, and try again. If the test |
156 | keeps on failing, this may indicate a problem with MOSI, MISO, nSEL, |
157 | SCLK, the power supply, the crystal oscillator, or possibly the position |
158 | of the transceiver chip. |
159 | <P> |
160 | Note: this test is meant as a higher level test. The GPIO test should |
161 | eventually provide more detailed results for problems with the SPI interface. |
162 | |
163 | |
164 | <!-- ---------------------------------------------------------------------- --> |
165 | |
166 | |
167 | <SUBSECTION title="Crystal frequency"> |
168 | |
169 | This test measures the frequency of the crystal oscillator in the DUT. |
170 | On <B>atben</B>, it does this by transmitting packets, and measuring |
171 | the time between the SLP_TR pulse that starts the transmission and the |
172 | interrupt signaling the end of the transmission. |
173 | On <B>atusb</B>, the microcontroller counts the clock cycles and the |
174 | number of cycles is compared with the PC's NTP-disciplined clock. |
175 | <P> |
176 | If this test fails, this may indicate that the load capacitors of the |
177 | crystal are missing, badly soldered, or have the wrong value. It could |
178 | also mean that the crystal itself is defective. Another possible cause |
179 | of oscillator malfunction could be flux residues bridging traces. |
180 | <P> |
181 | The <A href="fault.html">fault analysis page</A> has more details on |
182 | testing the crystal oscillator. |
183 | |
184 | |
185 | <!-- ---------------------------------------------------------------------- --> |
186 | |
187 | |
188 | <SUBSECTION title="Spectrum"> |
189 | |
190 | The spectrum test measures the reception of a signal sent from the |
191 | reference device to the DUT. It does this across the entire frequency |
192 | range in which the WPAN boards operate, allowing the detection of |
193 | frequency-dependent anomalies. |
194 | <P> |
195 | This test depends on numerous external factors, like the exact position |
196 | and orientation of the two devices with respect to each other, and the |
197 | presence of obstacles and conductive items (metal, people, etc.). |
198 | Because of the test's sensitivity |
199 | to environmental factors, the operator needs to decide when the result |
200 | represents a valid measurement and then confirm the result shown. |
201 | <P> |
202 | The image below shows the typical display during the spectrum test: |
203 | the white line is the measured signal strength. The red lines indicate |
204 | the minimum and maximum allowed values. The green circle in the upper |
205 | right corner indicates that the signal strength is within the limits. |
206 | A downward-pointing red triangle would indicate that the signal is too |
207 | weak, an upward-pointing yellow triangle would indicate that the signal |
208 | is too strong. |
209 | <P> |
210 | <A href="atrf-path.png"><IMG src="atrf-path-small.png"</A> |
211 | <P> |
212 | To finish the test, the operator must type either <B>P</B>, <B>F</B>, |
213 | or <B>Q</B>. <B>P</B> means "pass" and can only be |
214 | entered if the measurement is within the limits. <B>F</B> means "fail" |
215 | and can only be entered if the measurements is outside the limits. |
216 | <B>Q</B>, quit, can be entered at any time and also fails the test. |
217 | |
218 | |
219 | <!-- ---------------------------------------------------------------------- --> |
220 | |
221 | |
222 | <SUBSECTION title="Receive"> |
223 | |
224 | In the receive test, the reference device sends a number of frames to the |
225 | DUT. The test program verifies correct reception of all the frames. A |
226 | device that has passed all the preceding tests should not encounter |
227 | problems in the receive test. If it does, there may be a problem with |
228 | the bypassing of the transceiver's 1.8 V supplies. |
229 | |
230 | |
231 | <!-- ---------------------------------------------------------------------- --> |
232 | |
233 | |
234 | <SUBSECTION title="Send"> |
235 | |
236 | The send test is like the receive test, but with the DUT acting as the |
237 | sender and the reference acting as the receiver. If a device passes the |
238 | receive test but fails the send test, there is probably an issue with |
239 | the bypass capacitors of the analog 1.8 V supply. |
240 | <P> |
241 | Another possible cause could a problem with the SLP_TR signal. The |
242 | GPIO test should eventually catch this issue, but it may currently |
243 | remain undetected until the send test. |
244 | |
245 | <END author="Werner Almesberger" date="<GEN_DATE>"> |
246 | </BODY> |
247 | </HTML> |
248 |