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
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).
- 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.
- 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.
- 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.
- 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).
The software is written for Python 3.6. It will not work with Python 2.x.
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
--
StephenWotton - 2018-11-23