Test data

Web pages are under development which wil provide summaries of the test results. They are likely to change without warning and are not likely to contain meaningful data at present.

A directory can be found here.

Hardware Installation

Module tester board

• RichPdmdbModuleTesterPCB

MuDaq

The topic RichMuDaq contains general information about the muDaq hardware,firmware and software. The supplementary information here is specific to the module testing environment.

Power

Use a 5V power supply (exact voltage is not critical but should not exceed 5.5V).

USB

Connect MuDaq to a USB2 port on the PC. Avoid connecting to a USB3 (SS) port.

Master link I2C

Production boards are delivered to the test facility without the e-fuses being set. Therefore initial configuration of the master GBTX requires an I2C interface. MuDaq can operate as an I2C master. The physical I2C link will be through an adapter that plugs into JP5 ("GBT Dongle") of the module tester board. This adapter also provides the hardware required to program the master GBTX e-fuses. The adapter is connected to the muDaq using a short flat ribbon cable. The connector pin assignments are documented in the RichMuDaq topic.

Optical links

MuDaq has 8 SFP ports. They are numbered differently on the PCB than in the firmware/software. The SFP usage is documented in the RichMuDaq topic.

Software Installation

The Java GUI

The Java GUI is called JPDMDBDepp. It can run on Windows or Linux. The latest version (described here) requires Java 11 and can be downloaded here. Unpack into your installation directory. Some files will require local customisations:

PDMDBKIT/testerSequence.xml
PDMDBKIT/doAnalysis.sh
PDMDBKIT/ncat-daemon.sh

You also need the Digilent Adept2 environment. Download from here

Setting up

See also RichMuDaq#Quick_start_guide

The microcontroller host Linux system must be prepared first to accept the network connections from the Java GUI.

As a user with sudo rights to allow connections to port 7999 through firewall (this has been added permanently on pcmi but the commands are given here for reference):

sudo iptables -I INPUT -i eth0 -p tcp -s 131.111.66.0/24 --dport 7999 -j ACCEPT
sudo iptables -I INPUT -i eth0 -p tcp -s 172.24.8.0/24 --dport 7999 -j ACCEPT

Create two named pipes that forward commands and responses between muDaq and tester

mkfifo -m 0666 /dev/shm/mudaq-to-mtb
mkfifo -m 0666 /dev/shm/mtb-to-mudaq

These special files will disappear if your system is rebooted.

The file attributes (ls -l command) should look something like this:

prw-rw-rw- 1 lhcbrich z5        0 Dec 12 12:21 mtb-to-mudaq
prw-rw-rw- 1 lhcbrich z5        0 Dec 12 12:21 mudaq-to-mtb

If the first character is not p, delete the files and create them again.

As lhcbrich in a separate terminal window run the following command:

ncat -v -k -l -c <absolute-directory-path>/ncat-daemon.sh 7999

Before doing so, you may need to edit ncat-daemon.sh to change the directory where your tester Python software is installed.

This program manages the network connection between the tester and the GUI and must always be running. The window may contain useful debug output.

GBTX configuration files

You may need to choose the GBTX configuration files for correct operation. For the module testing, TCM.VCXO.gbt can be used for the TCM GBTX and DTM-noXPLL.gbt for all 6 DTM GBTXs. The TCM file should be set in the Master GBTX I2C... and Master GBTX IC... panels and the DTM file can be set in the Master link... panel.

Python software

The Python software forms the interface between the Java muDAQ software and the microcontroller firmware. It is made up of four files (modules).

1. serial_interface.py provides methods for communicating with the microcontroller firmware, particularly checking for responses and errors. You should not need to run or modify this file, although it must be present.
2. udaq_interface.py provides methods for communicating with the muDAQ firmware, particularly checking for responses and errors. You should not need to run or modify this file, although it must be present.
3. module_test_functions.py provides functions for running each test on the microcontroller. You may need to change the name of the microcontroller serial port on line 13 of this file, depending on your system configuration, but you should not need to run it directly.
4. test_supervisor.py is a process that waits for commands from the muDAQ, then runs the appropriate test on the microcontroller and returns the result to the muDAQ. You need to have this program running for the communication between the muDAQ and microcontroller to work. A summary of messages sent and received will be printed to the terminal it it running in. You may need to change the name of the microcontroller serial port on line 20 of this file, or the pipe names on line 19 (depending on your system configuration). This should be the only file you need to run directly (see below).

In normal operation the python program is launched automatically when a connection is made from the Java GUI.

Operating Instructions

Change to the PDMDBKIT directory in your installation area, for example:

On Linux:

cd /lhcb/lhcbrich/Upgrade/PDMDBTesting/PDMDBKIT/
<path-to-java11-installation>/bin/java @JPDMDBDepp.lnx

On Windows (Cygwin)

cd /cygdrive/q/lhcb/lhcbrich/Upgrade/PDMDBTesting/PDMDBKIT/
<path-to-java11-installation>/bin/java @JPDMDBDepp.win

The testing process

It is best to leave MuDaq always powered but the TCM and DTM power must be off when mounting and dismounting the plug-ins. The test sequence should do this automatically but it is important to check.

The principal steps of each automated test cycle are:

• Prepare the test environment
• Mount plug-ins on the tester board
• Scan plug-in QR codes
• Initial power test
• Program the TCM e-fuses
• Perform functional tests
• Run analysis
• Repeat from the beginning

During the testing process, all commands and responses are recorded and datasets containing eye scan and phase scan data are saved. A new data directory is created for each test cycle. A standalone program extracts the test results from these datasets and generates a test report summary for each module.

Note that the test sequence runs in an infinite loop but will wait for input at the QR scan step. Therefore this is a convenient point at which to replace the plug-in modules. The test sequence will continue automatically after the last QR code is scanned.

The sequence can be interrupted by clicking Pause. The sequence will then stop at the end of the currently running step. In case of error, it is best to restart the cycle from the beginning.

Notes on e-fusing

Special care must be taken to monitor that the e-fusing is proceeding correctly. If there is any doubt, do not continue the testing process until the problem is understood and resolved. E-fusing is an irreversible process.

Some extra checks are done in the automatic sequence and the e-fusing is disabled if any problem is detected. The software checks whether the master GBTX has already been fused and will skip the e-fusing in this case. This is not regarded as an error as it is likely that a test cycle will sometimes have to be repeated so the sequence should continue normally in this case.

As additional protection, a software token must be granted to enable the e-fusing process. The token automatically expires after some time (currently 25 hours) to avoid that e-fusing is unintentionally left enabled for long periods. The token can be granted/extended from the main test sequence panel. It can also be manually expired and it is recommended to do this at the end of testing shift. If the test cycle fails because the e-fusing token has expired, simply grant/extend the token and restart the test cycle.

Notes on handling of the hardware

• Take reasonable precautions against static discharge.
• Use the correct (JIS) screwdriver to attach the optical modules - one screw is sufficient closest to the module edge. Do not over-tighten.
• Use a jig when attaching the stand-off. Do not apply force to any other component.
• Carefully replace the MEGARRAY connector covers and optical module protectors when the modules are not plugged in.
• Keep the modules in their anti-static bags except while under test.
• Visually inspect the MEGARRAY connectors (both mating parts) before plugging any module.
• When removing a module use an appropriate tool to secure the transitional adapter.
• Remove a module by lifting the front edge. Avoid twisting/rocking. Avoid using the VTTX/VTRX as a handle.
• When mounting a module gently allow it to align itself and press down gently but firmly directly over the MEGARRAY connector - avoid twisting/rocking.
• If the transitional adapters are damaged, replace them.

Command reference

• RichPdmdbMTBCommands