ELOG Layer 1 Replacement

Latest tests of PH optimization

We did some tests by running the latest version of pXar on modules M1521, M1529, M1534 and M1536, specifically trimming and PH optimization. Of the 4 modules tested, the PH optimization converged only for M1521. We plan to further investigate with Urs' help possible reasons for failed PH optimization.

We also noticed a change in the threshold distribution plot of the latest trim bit test compared to the previous version of the test (see attached plots).

Attachment 1: TrimBitTest_old.png

Attachment 2: TrimBitTest_new.png

Mon Jan 20 18:09:50 2020

Activities 20.-31.01.2020.

20.01.

Expanded the HDI testing setup to be able to mount wire-bonded HDIs to HDI handles. Tested 12 HDIs (v7.2), all of them passed the tests. HDIs were given to Silvan and are located in the storage box in the assembly lab. They will be used for module production.

21.01.

Tested 4 HDIs, version 7.1. All passed the electrical tests.
Tested 16 v7.2 HDIs. All but one passed the electrical tests.
Glued a protection cap on a pre-production module (M1535).

22.01.

Investigated problems with full qualification setup, narrowed it down to communication between PC and Keithley.

23.01.

Tested 23 HDIs. One failed the test, rest of them passed.

24.01.

Tested 15 HDIs. All of them passed the tests.
Investigated problems with threshold/trim tests in full qualification when going to -20. Suspecting wrong DACs used in the test.

27.01.

Continuing to investigate problems with threshold in trimming procedures. The problem seems to be in the DAC 'ctrlreg' which was set to 17. Setting it to 9 removed the problem for M1529.

28.01.

Confirmed that 'ctrlreg' works also at room +20 degrees. Did reception test on modules 1529, 1536, 1537 and 1538. After this, caps were glued to modules 1537 and 1538. Did fulltest@-20, IV@-20, fullltest@+10 and IV@+10 for modules 1534, 1532, 1529 and 1536.

29.01.

Ran reeption on moules 1539 and 1540. Ran full qualification on modules 1536, 1537, 1538, 1540. Module 1539 turned out to have broken wirebonds on one TBM, reported this to Silvan and he re-bonded it. Assembled a second cap-gluing station.

Mon Jan 20 13:47:33 2020

pXar code updated

Dinko Ferencek wrote:

pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3 to https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c which pulled in the latest updates to the pulse height optimization test. Today a few remaining updates were pulled in by going to the current HEAD of the master branch https://github.com/psi46/pxar/tree/5d358c5ebbf095a7d118cdde9e1e509c41ccc615.

The sequence of commands to update the code was the following:

cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install

pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/9eb0f3844e9c7f98d7701629c5af339632c5d84a to pick up the latest update that allows running of the fullTest() method of each of the tests from the command line and consequently also from elComandante.

pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/f6e42c17c0bb3a44bdb3fa13d8f8afb6cae62a81 to pick up the latest PH optimization updates.

Tue Dec 3 12:15:54 2019

Andrey Starodumov

Full test

4 modules FT

Andrey Starodumov wrote:

FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
1) 2-6 ROCs with TrimBit test failure for many pixels
2) Trimming id bad for some ROCs
3) test at +10C often better than at -20C
4) some ROCs have issues with Thr and Gain distributions (out of specifications)

To be understood before the mass production!

We have run with Urs TrimBit test for M1526 at room T (without turning ON coldbox)
and results are confirmed yesterday observations of TrimBit test failure of several ROCs.
Urs will take a look and try to understand the issue.

To illustrate the problem below two summary tables of M1526 at -20C and +10C are shown.

Attachment 1: M1526ATm20.png

Attachment 2: M1526ATp10.png

Mon Dec 2 17:29:06 2019

Andrey Starodumov

Full test

4 modules FT

FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
1) 2-6 ROCs with TrimBit test failure for many pixels
2) Trimming id bad for some ROCs
3) test at +10C often better than at -20C
4) some ROCs hav issues with Thr and Gain distributions (out of specifications)

To be understood before the mass production!

Fri Nov 29 17:06:26 2019

Dropbox folder on CERNBox set up

A dropbox folder for elComandante tar files was set up in my CERNBox and synchronized with the following local folder on the lab PC

/media/disk1/DATA/L1_DATA_Backup/CERNBox_Dropbox/

Note that the following link in the home folder

/home/l_tester/DATA

points to

/media/disk1/DATA/

so an alternative path is

/home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/

The CERNBox client was installed on the lab PC following instructions for Ubuntu at https://cernbox.cern.ch/cernbox/doc/linux.html

Thu Nov 28 18:58:30 2019

Updated Fulltest configuration

The Fulltest definition used on the lab PC and stored in /home/l_tester/L1_SW/elComandante/config/tests/Fulltest had the following content

pretest
FullTest
bb2
exit

where FullTest is defined in https://github.com/psi46/pxar/blob/9eb0f3844e9c7f98d7701629c5af339632c5d84a/tests/PixTestFullTest.cc#L82-L121. For added flexibility, we would like to have individual tests specified in the definition file. However, by default this implies calling the doTest() method for each of the tests while FullTest actually calls the fullTest() method. For Scurves and GainPedestal the two methods are distinct. After the latest updates from Urs to the pXar code, we are now able to change the definition to

pretest
readback
alive
bb
bb2
scurves:fulltest
trim
ph
gainpedestal:fulltest
exit

Note that readback was placed first because in the past it was observed that pXar had a tendency to crash when this test was run last.

Thu Nov 28 18:34:00 2019

pXar code updated

Dinko Ferencek wrote:

cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install

Thu Nov 28 18:23:31 2019

Reorganized pXar configuration files for pixel modules

Dinko Ferencek wrote:

Due to different DAC settings needed for PROC V3 and V4, a single folder containing module configuration files cannot cover both ROC types. To address this problem, the existing folder 'tbm10d' in /home/l_tester/L1_SW/pxar/data/ containing configuration for PROC V4 was renamed to 'tbm10d_procv4' and a new folder for PROC V3, 'tbm10d_procv3', was created. For backward compatibility, a symbolic link 'tbm10d' was created that points to 'tbm10d_procv4'.

The difference in the configurations is in the CtrlReg DAC value which is 9 for V3 and 17 for V4.

The following lines were also added in the [defaultParameters] section in /home/l_tester/L1_SW/elComandante/config/elComandante.conf

tbm10d_procv3: tbm10d_procv3
tbm10d_procv4: tbm10d_procv4

Since the new PH optimization code was added under the already existing PH test, the old configuration files would have to be updated to have the correct parameter values set for the expanded PH test. For this purpose, the old configuration folders were renamed

tbm10d_procv3 --> tbm10d_procv3_old
tbm10d_procv4 --> tbm10d_procv4_old

and new configuration files were re-generated from scratch

./mkConfig -d ../data/tbm10d_procv3 -t TBM10D -r proc600v3 -m
./mkConfig -d ../data/tbm10d_procv4 -t TBM10D -r proc600v4 -m

In addition, in both sets of configurations files, the configuration for the BB2 tab in the pXar GUI was moved from moreTestParameters.dat to testParameters.dat to have the BB2 tab available by default when starting pXar using these configuration files.

Thu Nov 28 15:58:20 2019

Activities 26.-29.11.2019.

26.11.

Prepared the tools for RD53A digital module assembly in the assembly lab
Investigated if the latest pXar commit solved the issue with PhOptimization, now called Ph, and it runs successfully.
Investigated the bump bonding issue in which pXar reports bad bumps, but we suspected that was not the case. And indeed, putting a source on top of the chip reported to have bad bumps and taking data shows that there are no bad bumps as reported by pXar. Our conclusion was that the BB test developed by PSI is not applicable for bumps bonded by Helsinki. BB2 seems to be appropriate.

27.11.

Assembled a Phase 2 digital module using good ROCs - 1A48, 1A47, 1A43, 1A42; being ROC 0,1,2 and 3, respectively.
Used X-ray box to confirm our BB findings yesterday and the results agree that there are no defective bumps (as reported by pXar) on M1534.

28.11.

Took a look at the assembled module and it seems that one corner of the HDI was not properly glued. There are also solder marks on a couple of pads so we decided not to wire-bond it.
Measured the alignment of the two assembled module (one module was assembled during my last visit) using the microscope. The discrepancies in the distance between HDI wire-bond pads and ROC wire-bond pads are around 200 microns. If we take the length of the module to be 4cm, this is less than half a degree of tilt.

Worked on presentation reporting these activities for the tracker week.

Attachment 1: 1-1.jpg

Attachment 2: 1-2.jpg

Attachment 3: 1-3.jpg

Attachment 4: 1-4.jpg

Wed Nov 27 21:50:02 2019

Reorganized pXar configuration files for pixel modules

Wed Nov 27 18:25:08 2019

pXar code updated

cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install

Wed Nov 27 08:39:24 2019

Bump bonding test investigation

The BB test on M1534 shows a lot of dead bunmps on C10 and some on C1 and C0 as well. Putting a source on top of the module shows that the pixels for which the test showed dead bumps are still able to read hits from the source. Therefore, it looks like the bumps are working, but the test is reporting them as defective. It turns out that the bumps used by Helsinki are different than the bumps used at PSI so a different test needs to be used. After trying all 4 BB tets in pXar, it was concluded that BB2 is the appropriate test to use.

Wed Nov 20 16:53:50 2019

Andrey

Full test

M1533 and M1534 FullQualification

FullQualification of two modules M1533 and M1534 has been done. Full time of the test is about 7hrs.
Test included: FT@-10C, IV@-10, 2Cycles from -10C up to +10C, FT@-10C, IV@-10C, Ft@1-C and IV@10C.
No issues observed.
To be understood:
1) why SCurves results (noise) empty?
2) why the number of ROCs with defects always -1?

Tue Nov 19 14:10:10 2019

Andrey

new modules M1533 and M1534

Yesterday Silvan wire bonded two new modules M1533 and M1534 that are both grade C due to high leakage current and a few ROCs with large number of defective bump bonds.
Today I run Reception1st test with IV at +10C for both modules and above features are confirmed.
The IV curves present on a MoreWeb webpage but the values of a leakage current in the table under the curve is 0A (?). May be it relates to the fact that it should be current at -150V shown,
while the voltage scan stops at -130V since one of the modules draw 98umA current at this voltage. If it so, the MoreWeb script should be corrected: the current taken at -150V or if voltage
is lower then it is taken at the last (highest) value.
Tomorrow a FullQualification will be run on both modules.

Thu Oct 31 10:41:12 2019

Issue with DTB_WWVASW

On 29th of October, an issue with DTB_WWVASW was noticed when trying to run FullQualification on 4 modules at the same time. On a tested, working module, setting Vana works but taking tornado plots (setvthrcomp) doesn't as well as other tests. Curiously enough, after switching the DTB with the one used for HDI testing (DTB_WRN13L) the problem was still there. This lead us to believe that the problem was with cables or ground. All cables and the adapter were tested and shown to be working fine. This is when we took a third DTB, put it in the same plae as previously WWVASW and WRN13L, connected all the cables and then the tests worked.

Conclusion of the tests is that DTB_WWVASW and DTB_WRN13L are suffering from the same failure mode. It was not noticed before on the WRN13L because it does not affect the HDI tests. This leaves us with 3 working DTBs for the FUllQualification tests.

Wed Oct 30 16:54:58 2019

Investigating the bug with the Keithley client

Matej Roguljic wrote:

We took module 1529 and tried recreating the issue observed in the beginning of October. To do this in a reasonable amount of time, a "shorttest" procedure was defined which consists only of pretest and pixelalive. Three runs were taken

Run number 1: Shorttest@10,IV@10
Run number 2: Shorttest@10, IV@10,Cycle(n=1, between 10 and -10), Shorttest@10, IV@10
Run number 3: Shorttest@10, IV@10, Cycle(n=5, between 10 and -10), Shorttest@10, IV@10

In runs 1 and 2, IV was done from -5 to -155 in steps of 10
In run 3, IV was done from -5 to -405 in steps of 10

No issues were observed during the tests themselves.

Running MoReWeb shows the Temperature, Humidity and Sum of Currents plots while individual tests show only Pixel Alive map. IV plot is missing in the MoReWeb output, however, it is present in the ivCurve.log file. Tried investigating why IV is not shown, but couldn't get to the bottom of it.

Tomorrow we'll use M1529 and M1530 in a FullTest to check if the problem would appear.

M1530 was put in the coldbox and qualification was started, but the pxar output was full of deserializer errors. The continuous stream of errors made the log file pretty large and slowed down the execution of the qualification so it was aborted. Later it was noticed that there are green depositions on the module like it was on the HDIs irradiated at 60Co facility in Zagreb which is probably why there were so many errors.

M1521 was used instead of M1530 along with M1529. Full qualification was launched around 11:00. It ended around 6:30 without any issues.

Running full qualification on 30.10. in the morning on modules 1510, 1529, 1521. Fourth module was not included since there was an issue with the 4th DTB which will be investigated late. Like the previous day, the qualification ended around 17:00 without issues. In conclusion, the issue is not present in the qualification setup at the moment.

Wed Oct 30 10:38:04 2019

Activities 28.-31.10.2019.

28.10. - Investigated a problem with the FullQualification setup, described more in this note
29.10. - Further investigated the aforementioned problem and worked on preparing the jigs for Phase2 dummy module building.
30.10. - Confirmed that the reported issue is not present at the moment on the qualification system. Glued dummy sensor to four phase2 ROCs. Built a FC7 nanoCrate.

Tue Oct 29 16:38:32 2019

Investigating the bug with the Keithley client

Matej Roguljic wrote:

Tue Oct 29 16:36:23 2019