The production testing is quite simple. Since each board has been completely characterized, and we know the layout is good, we can just look for gross errors.
There are multiple test files for the different boards. (all in github).
The tests and test parameters are in in the
./iio-oscilloscope/profiles/FMComms2_test.ini file. This is broken down into the following sections:
<source master/profiles/FMComms2_test.ini:/temp/-/^$/ shell iio-oscilloscope>
ad7291.in_temp0_raw is the raw results from the AD7291 - which is 0.25°C. 80 refers to 80 steps of 0.25°C or 20°C, and 160 refers to 40°C. This allows the tests to be done in a normal lab setting. While the AD9361 & speced over the full industrial temperature range (−40°C to +85°C), the typical numbers in the datasheets are provided at a TA of 25°C, and this is where the test numbers come from.
<source master/profiles/FMComms2_test.ini:/number/-2/^$/ shell iio-oscilloscope>
This section needs a quick peek at the schematics. Sheet 3 shows how the AD7291 is connected. 1% resistors connect various voltages, and things are divided down to ensure that the voltage levels don't exceed full scale.
VDDA_GPO should be between 1.8 and 3.3V (according to the datasheet, and comes from 3P3V (on the schematic), which is the 3.3V pins on the FMC connector (which is spec'ed to ±5% in the FMC spec), we can assume that things will be 3.3V ± 5%, or 3.135V to 3.465V. This 3.135V to 3.465V translates to 1.929231 to 2.132308V (due to the 16k/(16k+10k) voltage divisor). Now that all that is left to do is determine the raw converter code values. To do this, it's just a simple matter of determining the LSB of the converters (in the AD7291 datasheet) - 12 bits, 2.5V full scale reference, or 2.5V / 2 12 or 0.0006103515625V per LSB. This means that 3161 and 3494 are the actual 12 bit codes that we should be comparing against.
These codes do not accounts for the ±1% resistors, and ±0.3% reference inside the AD7291, and the ±4.5 LSB (for worse case Offset Error from the AD7291).
|Input channel||Description||Nominal Voltage||Tolerance||VHIGH||VLOW|
|Voltage||(16kΩ+1%)/(16kΩ+1%+10kΩ-1%)||Codes 1)||Voltage||(16kΩ-1%)/(16kΩ-1%+10kΩ+1%)||Codes 2)|
Other boards (like FMCOMMS5) need to monitor other voltages, but use the same scheme.
|Voltage||(16kΩ+1%)/(16kΩ+1%+10kΩ-1%)||Codes 3)||Voltage||(16kΩ-1%)/(16kΩ-1%+10kΩ+1%)||Codes 4)|
It's just a matter of determining what the voltage should be (by following it back on the schematic), and doing a few simple calculations.
<source master/profiles/FMComms2_test.ini:/channels/-5/^$/ shell iio-oscilloscope>
This sets and checks various RF settings - it should be mostly human readable. If it's not, please ask.
For the FMCOMMS2/3/4, where the AD9361/64 are tied to a crystal, there is the ability to “tune” the crystal by making micro adjustments to the frequency in order to ensure that it matches its target station. This is calibrated during the tests using a frequency counter that continuously seeks towards the reference clock frequency while adjusting coarse and fine registers. Once it's as close as possible to the reference clock, the coarse and fine tuning values are stored as ASCII into the FRU EEPROM in the “Tuning” field using a command similar to the following:
# fru_dump -i /sys/bus/i2c/devices/0-0051/eeprom -o /sys/bus/i2c/devices/0-0051/eeprom -t 0c0bb8
Note that the value passed to the tuning option consists of two hex bytes for the coarse value followed by 4 hex bytes for the fine value, i.e. coarse = 12 and fine = 3000 in the command above
For the FMCOMMS5, only the current value of the reference clock is measured and saved since it doesn't support the coarse/fine tuning mechanism.
First, write the latest available SD card image found at https://wiki.analog.com/resources/tools-software/linux-software/zynq_images to a spare card and prepare the card to boot into Linux as detailed on that page for the target FMCOMMS and carrier boards (copy the right BOOT.BIN and devicetree.dtb files into the base directory of the SD card's boot partition).
Then the card needs to be modified to run the tests automatically on boot. Test scripts are provided in https://github.com/analogdevicesinc/linux_image_ADI-scripts that automate initializing osc with the correct profile and environment.
Note that different boards use different tests scripts as seen in the following mapping:
Select the correct script above for target test setup and alter the launcher for osc to run that test script instead of a regular osc instance. See the following example diff for required changes to the launcher to run the FMCOMMS2/3 tests on boot:
--- ./.config/autostart/config_autostart_osc.desktop 2013-12-09 15:55:41.774730469 -0500 +++ ./.config/autostart/config_autostart_osc.desktop 1969-12-31 19:20:18.000000000 -0500 @@ -1,11 +1,11 @@ [Desktop Entry] Type=Application -Exec=/usr/local/bin/osc +Exec=sudo /usr/local/bin/test_fmcomms2.sh Hidden=false NoDisplay=false X-GNOME-Autostart-enabled=true