Wiki

Analog Devices Wiki

English
English
简体中文
简体中文
日本語
日本語
Руccкий
Руccкий
no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.


—resources:eval:user-guides:pzsdr:testing [07 Apr 2021 17:11] – [Test process] Mihai Ionut Suciu
Line 1: Line 1:
  
 +====== PicoZed SDR production testing ======
 +
 +===== SOM =====
 +
 +==== Overview ====
 +
 +The SOM tests run during the U-Boot POST phase either as native U-Boot POST tests or loaded no-OS binaries that run and return a pass or failure status. See the following list for summaries of the current tests:
 +
 +  * USB media: Data is saved to an attached USB media drive, read back, and verified. If the data is different or there are other USB issues (device not attached, enumeration problems, etc) the test will fail.
 +  * Ethernet: The breakout board give itself a static IP address and tries to ping the computer's static address that it's directly connected to. The test passes if a response is received, otherwise it fails.
 +  * FPGA loopback: Electrical connectivity is tested using the test fixture attached to the breakout board via a loaded no-OS binary.
 +  * AD9361: The RF performance and related factors for the ad9361 part are tested via a loaded no-OS binary. Note that all the TX<->RX loopbacks are required otherwise the tests will fail.
 +
 +On completion, a script interactively runs through a few post test procedures including writing required files to QSPI flash in order to allow booting from it, querying a connected frequency counter to store the actual AD9361 reference clock out frequency as well as allowing the user to enter in the remaining suffix for the board's MAC address. These values are saved as variables to the U-Boot environment, also stored in flash memory.
 +
 +==== Test image ====
 +
 +The production test software running on the target device is available as a prebuilt image that can be written to an SD card in the same fashion as the ADI Zynq images. Instructions are available for writing images from [[/resources/tools-software/linux-software/zynq_images/windows_hosts|Windows]] or [[/resources/tools-software/linux-software/zynq_images/linux_hosts|Linux]].
 +
 +<WRAP lo round download 80%>
 +  * **5 January 2016 release **
 +  * [[http://swdownloads.analog.com/cse/picozed/picozed-sdr2-brk-test-2016_01_05.img.xz|Actual file for SOM2 Testing]]
 +  * Checksum picozed-sdr2-brk-test-2016_01_05.img.xz ''f070bb467a23d42f3bebe25f70876ed2''
 +  * Checksum picozed-sdr2-brk-test-2016_01_05.img ''9fefaa3910f3d6103704978b848fbfd6''
 +  * **14 August 2020 release **
 +  * [[https://swdownloads.analog.com/cse/prod_test_rel/picozed_test/picozed-sdr2-brk-test-2020_14_08.img.tar.xz|Actual file for SOM2 Testing]]
 +</WRAP>
 +
 +<WRAP center round important 60%>
 +It is also possible to manually create one using [[/resources/eval/user-guides/pzsdr/testing/sd-cards#som2|these instructions]].
 +</WRAP>
 +
 +<WRAP lo round download 80%>
 +  * **14 August 2020 release **
 +  * [[https://swdownloads.analog.com/cse/prod_test_rel/picozed_test/picozed-sdr1-brk-test-2020_14_08.img.tar.xz|Actual file for SOM1 Testing]]
 +</WRAP>
 +
 +<WRAP center round important 60%>
 +It is also possible to manually create one using [[/resources/eval/user-guides/pzsdr/testing/sd-cards#som1|these instructions]].
 +</WRAP>
 +
 +
 +==== Test script ====
 +
 +A Python script is used to automate post-test functionality that runs various U-Boot commmands. Specifically it is used to save the board model and AD9361 reference clock frequency to the U-Boot environment in addition to writing all the required boot files to QSPI flash in order to support booting Linux directly from it.
 +
 +The script can be fetched and run as follows:
 +
 +<code>
 +git clone https://github.com/analogdevicesinc/board-tests.git
 +cd board-tests/picozed-sdr2-brk
 +sudo ./pexpect-uboot
 +</code>
 +
 +==== Required hardware ====
 +
 +  * Frequency counter with a USB-GPIB port (tested with an [[https://www.rohde-schwarz.com/fi/product/hm8123-productstartpage_63493-44102.html|Hameg HM8123]]) with dual-probe attachment;
 +  * Raspberry Pi 4 with provided Linux image, keyboard, mouse HDMI cable, and a monitor with HDMI input;
 +  * 1 PicoZed SDR breakout board and loopback test fixture;
 +  * 1 PicoZed SDR module (SOM1 or SOM2);
 +  * 1 microSD card with the latest test image;
 +  * 1 Ethernet cable: either regular patch cable or crossover works fine;
 +  * 1 USB media drive with type A to micro OTG adapter;
 +  * 2 USB cables: one type A to micro to attach from the Raspberry Pi to the board's UART port and one type A to type B to attach from Raspberry Pi to the GPIB-USB controller on the frequency counter;
 +  * 4 RF loopback cables for SOM2 (2 for SOM1).
 +
 +==== Required setup ====
 +
 +  * Raspberry Pi 4 with attached mouse and keyboard running the provided python script and an Ethernet cable plugged into both the breakout board and the Raspberry Pi. In addition, two USB cables should be plugged into the Raspberry Pi board: the first goes to the UART port on the breakout board and the second goes to the USB-GPIB module on the frequency counter.
 +{{ resources:eval:user-guides:pzsdr:raspberry_pi_4_setup.jpg?600 }}
 +  * See the picture below for what should be displayed in the terminal on the monitor when the script is ready and waiting for output from the device.
 +{{ resources:eval:user-guides:pzsdr:pzsdr-som-script-ready.png }}
 +  * If instead, you see an error similar to what is shown in the image below, then the USB cables for the UART and/or frequency counter have not been properly plugged into the Raspberry Pi running the test script or the breakout board and frequency counter are not powered on. Confirm that the USB cables are plugged in on both sides and the devices are powered on then hit enter to properly initialize the script. If everything is working, output similar to that seen in the previous image should be shown.
 +{{ resources:eval:user-guides:pzsdr:pzsdr-som-script-error.png }}
 +  * Make sure the frequency counter is set to use a GPIB address of 16. On the Agilent 53131A, the current GPIB address is shown on the screen in the form of a message similar to "GPIB AT 16" soon after power on. To set it, see section 3-4 "Configuring the GPIB" in the [[http://fy.chalmers.se/~f7xlh/elmatB/Instrument/53131_Prog.pdf|Agilent 53131A user guide]]. 
 +  * The probes for the frequency counter should be attached to the pin on the fan plugin nearest the power switch on the breakout board and to a ground location such as the pin accessible through the cutout on the side of the JTAG header. See the picture below for a view of the probe locations. Also, note the labels on the USB ports in order to plug them in the right locations for the media drive and UART connection to the Raspberry Pi.
 +{{ resources:eval:user-guides:pzsdr:pzsdr2-test-setup.jpg }}
 +  * Make sure the USB jumper is set to OTG mode on the breakout board, see the image above for confirmation of correct positioning.
 +  * SOM module plugged into a breakout board modified for performing a connectivity loopback test. Make sure the boot select switches are set to boot off the SOM's SD card and that a SD card containing the production test software is inserted. See the image below for proper boot select switch positions.
 +{{ resources:eval:user-guides:pzsdr:pzsdr-som-bootselect.jpg }}
 +  * SOM2 has loopbacks placed between TX1A<->RX1A, TX1B<->RX1B, TX2A<->RX2A, and TX2B<->RX2B as seen in the first image below. SOM1 has loopbacks placed between TXA<->RXA and TXB->RXB as seen in the second image.
 +{{ resources:eval:user-guides:pzsdr:pzsdr-rf-loopback.jpg }} {{ resources:eval:user-guides:pzsdr:pzsdr1-rf-loopback.jpg }}
 +
 +==== Test process ====
 +
 +First, make sure all the required setup explained above is completed and the frequency counter is turned on in addition to the Raspberry Pi running the test script. Once the test setup is ready, SOM testing should be done using the following steps:
 +
 +  - Place a new SOM module onto the breakout board.
 +  - Insert an SD card with the production test software into the SOM card slot.
 +  - Power on the breakout board.
 +  - Hit the blue button on the SOM to reset the board and start the test (see picture below). {{ resources:eval:user-guides:pzsdr:pzsdr-som-reset.jpg }}
 +  - Confirm the green power LED and blue FPGA LED are both lit after a few seconds have passed (see the picture below). If two green LEDs are lit on the SOM without the blue FPGA LED being lit this means that the FPGA isn't getting configured properly which means there is an issue during early bring up such as the board's power sequence not running correctly. {{ resources:eval:user-guides:pzsdr:pzsdr-som-poweron-leds.jpg }}
 +  - Now the terminal should start showing output from U-Boot starting up and running the tests as part of its power on self-testing framework.
 +  - When the tests pass on a SOM2, the DS3 through DS6 LEDs will be solid. For SOM1 only DS3 will be lit. See the images below for an example of LEDs lit after a successful test run, the SOM2 image is first then SOM1. {{ resources:eval:user-guides:pzsdr:pzsdr-som-passed.jpg }} {{ resources:eval:user-guides:pzsdr:pzsdr1-som-passed.jpg }} If tests fail, the script will note that tests failed and automatically restart. Also, the LEDs mentioned previously should be blinking on the breakout board. When this occurs, turn off the breakout board, remove the SOM, and restart with step 1. See the image below for what is output on the terminal after a failed test run. {{ resources:eval:user-guides:pzsdr:pzsdr-som-script-failed.png }}
 +  - Next, the script should start sending commands to the U-Boot console as part of the post-test process. The majority of this time is spent writing various files to QSPI flash, specifically: U-Boot, kernel, device tree, rootfs, and FPGA bitstream files are all written.
 +  - When prompted on the Raspberry Pi monitor, enter in the remaining suffix characters to set the MAC address for the board. Note that the MAC address prefix defaults to Avnet's OUI + SOM prefix (0002B501). Therefore, if you enter in the example suffix of "fa34", the MAC address saved to the environment will be 00:02:b5:01:fa:34. {{ resources:eval:user-guides:pzsdr:pzsdr-som-script-mac.png }}
 +  - When the process is complete, the following window should be shown on the Raspberry Pi monitor. At that point power off the breakout board and remove the SOM. Then the process can be restarted at step 1 to test the next SOM. {{ resources:eval:user-guides:pzsdr:pzsdr-som-script-done.png }}
 +
 +===== FMC Carrier =====
 +
 +==== Overview ====
 +
 +The carrier tests run on boot up into Linux via a script in a terminal window. See the following list for summaries of the current tests:
 +
 +  * USB media: Data is saved to an attached USB media drive, read back, and verified. If the data is different or there are other USB issues (device not attached, enumeration problems, etc) the test will fail.
 +  * Ethernet: A cable is connected between the board's Ethernet ports and a ping between them is forced over the wire. The test passes if a response is received, otherwise it fails.
 +  * Audio: A tone is played and recorded on sets of looped back audio channels. Then the recorded file is analyzed to determine the frequency of the recorded tone matches the input frequency.
 +  * HDMI: Monitor connectivity is checked in addition to physical displaying output on the attached monitor.
 +  * SFP+, PMOD, Camera, FMC: All of these use loopback boards or modules to perform basic electrical connectivity tests.
 +
 +==== Test image ====
 +
 +The production test software running on the target device is available as a prebuilt image that can be written to an SD card in the same fashion as the ADI Zynq images. Instructions are available for writing images from [[/resources/tools-software/linux-software/zynq_images/windows_hosts|Windows]] or [[/resources/tools-software/linux-software/zynq_images/linux_hosts|Linux]].
 +
 +<WRAP lo round download 80%>
 +  * **5 January 2016 release **
 +  * [[http://swdownloads.analog.com/cse/picozed/picozed-sdr2-fmc-test-2016_01_05.img.xz|Actual file]]
 +  * Checksum picozed-sdr2-fmc-test-2016_01_05.img.xz ''11bf4ff54201ae7c7fa97ac134f53bca''
 +  * Checksum picozed-sdr2-fmc-test-2016_01_05.img ''99e5260753c6e1a3d8245a66f5cbb337''
 +</WRAP>
 +
 +==== Required hardware ====
 +
 +  * 1 Ethernet cable
 +  * 1 SFP+ loopback module
 +  * 2 1/8" audio loopback cables
 +  * 1 FMC loopback card (tested using the ApisSys AF101)
 +  * 1 Camera loopback module
 +  * 1 PMOD loopback module
 +  * 1 USB media drive
 +  * 1 type A to micro OTG adapter
 +  * 1 USB hub
 +  * 1 type A to micro USB cable to attach from the computer to the board's UART port
 +  * 1 PicoZed SDR2 SOM module
 +  * 1 PicoZed SDR2 FMC carrier board
 +  * 1 microSD card and SD adapter with the latest test image ([[/resources/eval/user-guides/pzsdr/testing/sd-cards#fmc_carrier|or manually create one]])
 +  * 1 External monitor with HDMI input
 +  * 1 External computer set up to monitor the serial connection
 +  * Keyboard and mouse to be connected to the carrier board
 +
 +==== Required setup ====
 +
 +  * SOM board plugged into a carrier board with the card and boot select switches set to boot from the carrier SD card slot (as seen in the image below). {{ resources:eval:user-guides:pzsdr:pzsdr-ccfmc-bootselect.jpg }}
 +  * SD card with tests inserted into carrier slot.
 +  * Ethernet cable plugged into both jacks on the carrier board.
 +  * Audio loopback cables plugged into horizontal sets of output/input jacks.
 +  * SFP+, FMC, camera, and PMOD loopback modules plugged in. Make sure the switches on the bottom of the FMC card are set as seen in the image below: {{ resources:eval:user-guides:pzsdr:pzsdr-ccfmc-fmc.jpg }}
 +  * USB media drive inserted into the USB hub that plugs into the OTG adapter and then into the carrier's USB OTG port.
 +  * Mouse and keyboard also plugged into the USB hub.
 +  * USB cable plugged into computer and the micro USB UART port on the carrier board.
 +  * HDMI cable plugged from the carrier board into the external monitor.
 +
 +See the following image of a board set up to run the production tests.
 +{{ resources:eval:user-guides:pzsdr:pzsdr-ccfmc-setup.jpg }}
 +
 +==== Test process ====
 +
 +First make sure all the required setup explained above is ready. Once that is done, testing carrier boards should be done using the following steps:
 +
 +  - Insert an SD card with the production test software into the carrier slot.
 +  - Power on the board.
 +  - The board should start up and run the loopback tests within U-Boot. If things fail at this stage, the process will stop, a relevant failure message will be shown on UART, and LEDS DS3 through DS6 will be flashing. If things appear to be hanging, confirm the green power LED and blue FPGA LED are both lit after a few seconds have passed (see the image below). If two green LEDs are lit on the SOM without the blue FPGA LED being lit this means that the FPGA isn't getting configured properly which means there is an issue during early bring up such as the board's power sequence not running correctly. {{ resources:eval:user-guides:pzsdr:pzsdr-ccfmc-poweron-leds.jpg }}
 +  - Next the board will continue to boot into Linux to run the remainder of the tests. Confirm the LEDS related to HDMI and UART are lit up as seen in the image above.
 +  - Tests should start automatically and be shown on the screen as seen below. Note that the mouse may have to be moved to force the HDMI output to display on the external monitor. {{ resources:eval:user-guides:pzsdr:pzsdr-ccfmc-running.png }}
 +  - When the tests pass, the DS3 through DS6 LEDs will be solid. See the picture below for an example of LEDs lit after a successful test run. {{ resources:eval:user-guides:pzsdr:pzsdr-ccfmc-passed.jpg }} If any test fails LEDs DS3 through DS6 will be blinking and the script output will note the failure. See the image below for what is output on the terminal after a failed test run. {{ resources:eval:user-guides:pzsdr:pzsdr-ccfmc-failed.png }}
 +  - Finally hit the Enter key to power down the system. The message "System halted" should be shown on the serial output when it's safe to physically toggle the power switch on the board.
 +
 +===== Breakout board =====
 +
 +==== Raspberry Pi test suite ====
 +
 +=== Overview ===
 +
 +The breakout board tests run via the U-Boot post testing framework while an attached Raspberry Pi automates the pass/fail mechanism via a looped expect script reading the breakout board's output over a serial connection. See the following list for summaries of the current tests:
 +
 +  * USB media: Data is saved to an attached USB media drive, read back, and verified. If the data is different or there are other USB issues (device not attached, enumeration problems, etc) the test will fail.
 +  * Ethernet: The breakout board give itself a static IP address and tries to ping the computer's static address that it's directly connected to. The test passes if a response is received, otherwise it fails.
 +  * Buttons: The user running the test must interactively toggle the buttons which triggers a LED to blink. Note that when using SOM1 boards only buttons S7, S8, and S9 are tested due to pin count limitations.
 +
 +=== Required hardware ===
 +
 +  * 1 Ethernet cable
 +  * 1 USB media drive
 +  * 1 type A to micro OTG adapter
 +  * 1 type A to micro USB cable to attach from the computer to the board's UART port
 +  * 1 two pin jumper to set the USB mode
 +  * 1 PicoZed SDR1 SOM module
 +  * 1 PicoZed breakout board and power adapter
 +  * 1 microSD card using the latest test image
 +  * 1 Raspberry Pi 2/3 with attached screen using the related test image
 +
 +=== Required setup ===
 +
 +  * Raspberry Pi 2/3 with SD card for the test suite inserted.
 +  * SOM1 board plugged into a breakout board with SD card for test suite inserted.
 +  * Ethernet cable plugged in between the breakout board and the Raspberry Pi.
 +  * USB media drive inserted into the USB hub that plugs into the OTG adapter and then into the breakout board's USB OTG port.
 +  * Two pin jumper inserted to enable USB OTG mode.
 +  * USB cable plugged into Raspberry Pi and the micro USB UART port on the breakout board.
 +
 +See the following images of a Raspberry Pi and breakout board set up to run the production tests. {{ resources:eval:user-guides:pzsdr:brkout-setup.jpg }} {{ resources:eval:user-guides:pzsdr:rpi-setup.jpg }}
 +
 +=== Test process ===
 +
 +First make sure all the required setup explained above is ready. Once that is done, testing breakout boards should be done using the following steps:
 +
 +  - Insert the SDR1 SOM board with test suite SD card into the breakout board.
 +  - Make sure the power, USB, and Ethernet cables are plugged in and then power on the board. Confirm the green power LED and blue FPGA LED are both lit after a few seconds have passed (see the picture below). If two green LEDs are lit on the SOM without the blue FPGA LED being lit this means that the FPGA isn't getting configured properly which means there is an issue during early bring up such as the board's power sequence not running correctly. {{ resources:eval:user-guides:pzsdr:pzsdr-som-poweron-leds.jpg }}
 +  - The board will start U-Boot which will run the tests after initialization.
 +  - Tests should start automatically and be shown on the serial terminal.
 +  - When prompted on screen as seen in the following image, toggle the buttons (S7 through S9) on the board. Note that the DS3 LED should light up when the buttons are in the on state. In order to pass the test the buttons must be toggled on and off within a minute of starting the test, otherwise the test will timeout and fail. {{ resources:eval:user-guides:pzsdr:rpi-button.jpg }}
 +  - When the tests pass, a related message will be shown on screen in green. If any test fails, a message will shown in red instead. The following images show what the screen should look like in these cases. {{ resources:eval:user-guides:pzsdr:rpi-pass.jpg }} {{ resources:eval:user-guides:pzsdr:rpi-fail.jpg }} 
 +  - Once the tests are complete, keep the Raspberry Pi running and turn off the breakout board. Then unplug the power, USB, and Ethernet cables from the breakout board in addition to removing the SOM1. Plug all the cables back into the next breakout board and repeat the process from the beginning.
 +
 +When done testing, hit button #23 on the Raspberry Pi to power down the system and give the system a few seconds before pulling the power cable. The screen should display a bunch of service stopping messages before finally stating "Starting Power-off" (as seen below) at which point it's safe to pull the power cable. {{ resources:eval:user-guides:pzsdr:rpi-poweroff.jpg }}
 +
 +==== Linux test suite ====
 +
 +=== Overview ===
 +
 +The breakout board tests run on boot up into Linux via a script. See the following list for summaries of the current tests:
 +
 +  * USB media: Data is saved to an attached USB media drive, read back, and verified. If the data is different or there are other USB issues (device not attached, enumeration problems, etc) the test will fail.
 +  * Ethernet: A loopback module is used to perform a simple loopback test.
 +  * Switches/buttons: The user running the test must interactively toggle the switches and buttons which trigger the related LEDs.
 +
 +=== Test image ===
 +
 +The production test software running on the target device is the [[/resources/tools-software/linux-software/zynq_images#download_linux_image|standard ADI Zynq image]] modified slightly to run the [[https://github.com/analogdevicesinc/board-tests/tree/master/picozed-brk|test suite]].
 +
 +=== Required hardware ===
 +
 +  * 1 Ethernet loopback module
 +  * 1 USB media drive
 +  * 1 type A to micro OTG adapter
 +  * 1 type A to micro USB cable to attach from the computer to the board's UART port
 +  * 1 two pin jumper to set the USB mode
 +  * 1 PicoZed SDR2 SOM module
 +  * 1 PicoZed breakout board and power adapter
 +  * 1 microSD card using the latest [[/resources/tools-software/linux-software/zynq_images#download_linux_image|ADI Zynq image]] configured to run the [[https://github.com/analogdevicesinc/board-tests/tree/master/picozed-brk|test suite]]
 +  * 1 External computer set up to monitor the serial connection
 +
 +=== Required setup ===
 +
 +  * SOM board plugged into a breakout board with SD card for test suite inserted.
 +  * Ethernet loopback module plugged in.
 +  * USB media drive inserted into the USB hub that plugs into the OTG adapter and then into the carrier's USB OTG port.
 +  * Two pin jumper inserted to enable USB OTG mode.
 +  * [[http://www.cypress.com/documentation/other-resources/usb-serial-drivers|Cypress USB driver]] installed for connecting to the UART on Windows (or the cp210x module loaded on Linux)
 +  * USB cable plugged into computer and the micro USB UART port on the breakout board and the computer running your favorite terminal emulator (e.g. TeraTerm, PuTTY, minicom, picocom, etc) connected to the related serial port.
 +
 +See the following image of a board set up to run the production tests.
 +{{ resources:eval:user-guides:pzsdr:pzsdr-ccbrk-setup.jpg }}
 +
 +=== Test process ===
 +
 +First make sure all the required setup explained above is ready. Once that is done, testing breakout boards should be done using the following steps:
 +
 +  - Insert the SDR2 SOM board with test suite SD card into the breakout board.
 +  - Make sure all the switches (S1 through S4) are set to the off position (they should all be toggled towards the label side as seen in the image above).
 +  - Make sure the power cable is plugged in and then power on the board. Confirm the green power LED and blue FPGA LED are both lit after a few seconds have passed (see the picture below). If two green LEDs are lit on the SOM without the blue FPGA LED being lit this means that the FPGA isn't getting configured properly which means there is an issue during early bring up such as the board's power sequence not running correctly. {{ resources:eval:user-guides:pzsdr:pzsdr-som-poweron-leds.jpg }}
 +  - The board will boot into Linux to run the tests.
 +  - Tests should start automatically and be shown on the serial terminal.
 +  - When prompted, toggle the switches (S1 through S4) and buttons (S6 through S9) on the board. Note that the related LEDs should light up when the switches or buttons are in the on state (e.g. LED DS3 should light up when switch S1 or button S6 are enabled). In order to pass the test all switches and buttons must be toggled on and off. If this is not done within a minute of starting the test, it will timeout and fail.
 +  - The others tests will run without requiring user input once the switch and button tests are finished.
 +  - When the tests pass, the DS3 through DS6 LEDs will be solid. See the picture below for an example of LEDs lit after a successful test run. {{ resources:eval:user-guides:pzsdr:pzsdr-ccbrk-passed.jpg }} If any test fails LEDs DS3 through DS6 will be blinking and the script output will note the failure.
 +  - Finally hit the Enter key to power down the system. The message "System halted" should be shown on the serial output when it's safe to physically toggle the power switch on the board.
 +
 +===== Breakout board Raspberry Pi test =====
 +
 +==== Overview ====
 +
 +The breakout board tests run via the U-Boot post testing framework while an attached Raspberry Pi automates the pass/fail mechanism via a looped expect script reading the breakout board's output over a serial connection. See the following list for summaries of the current tests:
 +
 +  *  **Buttons**: The user running the test must interactively toggle the buttons which trigger a LED to blink. Note that when using SOM1 boards only buttons S7, S8, and S9 are tested due to pin count limitations.
 +  *  **USB media**: Data is saved to an attached USB media drive, read back and verified. If the data is different or there are other USB issues (device not attached, enumeration problems, etc) the test will fail.
 +  *  **Ethernet**: A loopback module is used to perform a simple loopback test. The test passes if a response is received, otherwise, it fails.
 +
 +==== Test images ====
 +
 +The production test software running on the target device is available as a prebuilt image that can be written to an SD card in the same fashion as the ADI Zynq images. Instructions are available for writing images from [[/resources/tools-software/linux-software/zynq_images/windows_hosts|Windows]] or [[/resources/tools-software/linux-software/zynq_images/linux_hosts|Linux]].
 +
 +<WRAP lo round download 80%>
 +  * **5 January 2016 release **
 +  * 
 +  * Checksum ''''
 +  * Checksum ''''
 +</WRAP>
 +
 +<WRAP lo round download 80%>
 +  * **Raspberry Pi image **
 +  * 
 +  * Checksum ''''
 +  * Checksum ''''
 +</WRAP>
 +
 +<WRAP center round important 60%>
 +It is also possible to manually create one using [[/resources/eval/user-guides/pzsdr/testing/sd-cards#breakout_board|these instructions]].
 +</WRAP>
 +==== Required hardware ====
 +
 +  *  1 Ethernet loopback module
 +  *  1 USB media drive
 +  *  1 type A to micro USB OTG adapter
 +  *  1 type A to micro USB cable to attach from the Raspberry Pi computer to the board's UART port
 +  *  1 two pin jumper to set the USB mode
 +  *  1 PicoZed SDR2 SOM module
 +  *  1 PicoZed breakout board and power adapter
 +  *  1 microSD card using the latest ADI Zynq image configured to run the test suite
 +
 +
 +==== Required setup ====
 +
 +<WRAP center round tip 80%>
 +This setup needs to be done only once.
 +</WRAP>
 +
 +**1. SDR2 SOM** board **with SD card inserted** configurated to run the test suite and **S1** dip switch on the **"SDSOM"** position.
 +{{ :resources:eval:user-guides:pzsdr:sdr2_som.jpg?400 |}}
 +\\
 +**2. USB** media drive into the **OTG** adapter.
 +{{ :resources:eval:user-guides:pzsdr:usb_drive_otg.jpg?400 |}}
 +\\
 +**3. Raspberry Pi powered on** configurated to run the breakout board test with a **USB cable attached**. After about a couple seconds the following message will be printed on the screen “POWER ON BRK”. At this point, the Raspberry Pi is ready to test the breakout board.
 +{{ :resources:eval:user-guides:pzsdr:raspberry_pi_setup.jpg?400 |}}
 +
 +
 +
 +
 +==== Test process ====
 +
 +**1.** Insert the SDR2 SOM board with test suite SD card into the breakout board.\\
 +
 +**2.** Make sure all the switches (S1 through S4) are set to the off position.\\
 +
 +**3.** Plug the micro USB on the UART port (P14) on the breakout board.\\
 +
 +**4.** Plug the OTG adapter into the breakout board USB OTG port (P11).\\
 +
 +**5.** Plug the Ethernet loopback module into breakout board Ethernet connector (M1).\\
 +
 +**6.** Insert a jumper on the P9 header, between pin 1 & 2, to enable USB OTG mode.\\
 +{{ :resources:eval:user-guides:pzsdr:breakout_board_setup.jpg?600 |}}\\
 +
 +**7.** Make sure the power cable is plugged in and then power on the board. Confirm the green power LED and blue FPGA LED are both lit after a few seconds have passed (see the picture below). If two green LEDs are lit on the SOM without the blue FPGA LED being lit this means that the FPGA isn't getting configured properly which means there is an issue during early bring up such as the board's power sequence not running correctly.\\
 +
 +**8.** The board will boot into Linux to run the tests.\\
 +
 +**9.** Tests should start automatically and be shown on the Raspberry Pi display.\\
 +{{ :resources:eval:user-guides:pzsdr:pzsdr-som-poweron-leds.jpg?600 |}}\\
 +
 +**10.** When prompted, toggle the switches (S1 through S4) and buttons (S6 through S9) on the board. Note that the related LEDs should light up when the switches or buttons are in the on the state (e.g. LED DS3 should light up when switch S1 or button S6 are enabled). In order to pass the test, all switches and buttons must be toggled on and off. If this is not done within a minute of starting the test, it will timeout and fail.\\
 +{{ :resources:eval:user-guides:pzsdr:start_toggle.png?250 |}}\\
 +
 +**11.** Wait for the test result. The other tests will run without requiring user input once the switch and button tests are finished. When the tests pass, the DS3 through DS6 LEDs will be solid.\\ 
 +| {{ :resources:eval:user-guides:pzsdr:test_pass.png?250 |}} | {{ :resources:eval:user-guides:pzsdr:pzsdr-ccbrk-passed.jpg?370 |}} |
 +
 +If any test fails LEDs DS3 through DS6 will be blinking and the script output will note the failure.\\
 +| {{ :resources:eval:user-guides:pzsdr:test_fail_toggle.png?250 |}} | {{ :resources:eval:user-guides:pzsdr:test_fail_usb.png?250 |}} | {{ :resources:eval:user-guides:pzsdr:test_fail_ethernet.png?250 |}} |\\
 +
 +**12.** Finally wait for "TURN OFF BOARD! CONNECT NEXT BOARD TO BE TESTED!" to power down the system.\\ 
 +| {{ :resources:eval:user-guides:pzsdr:test_pass_end.png?250 |}} | {{ :resources:eval:user-guides:pzsdr:test_fail_end.png?250 |}} |\\
 +
 +**13.** Once the test is complete turn off the breakout board, unplug the power, USB cables and Ethernet loopback module from the breakout board in addition to removing the SDR2 SOM. Plug all the cables back into the next breakout board and repeat the process from the beginning. If you want to start the test again, for the same breakout board, power off and then power on the breakout board or reset the SDR2 SOM board to repeat the test automaticaly.\\
 +
 +**When done testing**, hit **button #27 on the Raspberry Pi display** to **power down** the system and give the system a few seconds before pulling the power cable.\\
 +{{ :resources:eval:user-guides:pzsdr:power_off_pi.png?250 |}}\\
 +
 +If necessary, hit **button #23 on the Raspberry Pi display to restart** or hit **button #22 to display the Raspberry Pi IP addresses**.\\ 
 +| {{ :resources:eval:user-guides:pzsdr:reboot_pi.png?250 |}} | {{ :resources:eval:user-guides:pzsdr:get_all_ip.png?250 |}} | |\\
 +
 +==== Demo Test process ====
 +
 +{{ :resources:eval:user-guides:pzsdr:breakout_board_test.gif |}}
 +\\
resources/eval/user-guides/pzsdr/testing.txt · Last modified: 20 Feb 2023 13:57 by Monica Constandachi

Page Tools