<!-- Title: 11:46:38  Fri Apr  4 2003 -->
<!-- Crewchief: SVT folks -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Page was getting too long</pre>


<!-- Date: Sat Apr 5 06:23:58 2003 -->
I turned out that yesterday night the aces did nto reboot SVT crates, in spite of their saying "yes boss we did it". I guess I should have checked (httpd server on crates tells the boot time). So tonight I put the new svtvme in "developmnet" again and rebooted. SVT has been running fine since. So I got bolder and am leaging it like this. SVT crates will reboot by default by the latest svtvme version that I pulled from CVS yesterday, i.e. the XTF map code is new one (yuppiee !). 
<br> 
<b>PAGER CARRIERS INFO: if disaster strikes and you are convinced you want to go back to svtvme as it was on March 30, do: 
</b> 
<ul> 
<li> ksu cdf_svt 
<li> setup svtvme 
<li> cd $SVTVME_DIR/.. 
<li> rm -r developmnet (make you you misspell it correctely !) 
<li> mv SAVEME  developmnet 
<li> reboot all crates (make sure they really reboot!!) 
</ul>
<!-- Author: Stefano -->


<!-- Date: Tue Apr 8 12:24:55 2003 -->
<pre>SVT crates rebooted to allow Jane N. to finally switch off  
the license manager. SPYMON is taking his SmartSocket licences fro the fake processess running inside the crate.  
This means that also the svtmon setup command was changed in  
/cdf/code-common/cdfonline/vxboot/ups/svtb.table to load the development version. 
 
 
 </pre>
<!-- Author: Marco  -->


<!-- Date: Fri Apr 11 23:09:06 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-92&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-92  width='300' align='top'></td><td>SVT beam position. Do we allow this large slope in x? It is about 700 urad.</a></td></tr></table>
<!-- Author: Un-ki -->


<!-- Date: Wed Apr 16 19:35:21 2003 -->
<pre>I got paged because the XFTA was not properly 
initialized at coldstart today at around 5 p.m. 
 
The error message was 
 
 
(MLE) b0svt07:Messenger:7:19:16 PM-&gt;FER_E_SVT, writeMap(spy_fanout/XTFAcrv): crc=379152629 
(MLE) b0svt07:Messenger:7:19:16 PM-&gt;FER_E_SVT, expect=957766496 
 
I first tried to switch on/off the crate, then swapped the board with the 
one in the test stand. I always got the same error. 
 
I then followed your instruction to back off the svtvme version as of 
prior the recent XFTA modification. 
 
It finally worked. I loaded the new version again, and it worked. 
But there is a catch here. Since the memory was finally correctly written 
by the old svtvme version, the CRC test was fine and the actual code 
to write the memory was not really executed.... To be sure of this 
I switched off the crate. Now I reproduced the error again.... 
 
I will leave the SAVEME version in $SVTVME_DIR/.. directory as developmnet 
for the time being. The original developmnet is called 
developmnet_16apr2003. 
 
I will also leave the test stand XFTA board in the crate for the time being. 
 
 
</pre>
<!-- Author: Marco  -->
<!-- Comment: Thu Apr 17 06;38;38 comment by...Stefano -->
<pre>It is a no-probleme, only an operational glitch.
Here is the bottom line, operational detail follow:
BOTTOM LINE: ALL THAT IS NEEDED IS TO PUT THE NEW CRC
IN THE MAP FILE, I.E IN THE MAP FILE REPLACE
957766496 WITH 379152629, PUT BACK THE LATEST SVTVME
DEVELOPMENT (OR REBUILD IT FROM CVS HEAD) AND REBOOT
THE CRATE. OF COURSE THIS REQUIRE:
1. SOMEONE WHO CAN WRITE IN THE DB
2. NO BEAM
ALL PEOPLE WHO CAN DO 1. ARE AT FNAL, AND THEY CAN ALSO
EASILY PICK THE PROPER TIME.

Here is the story:
The XTFA is/was fine. But it is true that even with no cut
on XFT Pt the CRVMAP ram image is different when using the
new svtvme code, becasue I now fill unused locations with 0
intead of ff (rational is that 0xff is a legal curavure bin
value, 0 not, so I will use 0 to flag pt bins below the cut
and in this way things are much more consistent and source
code has some hope of being understandble and thus maintainable).
I checked this on the XTFA board in the test stand, cold starting
it from the two versions (old and new) of svtvme and using
svtgui (thanks Subir !) to dump XTFA_CRVMAP content to a file.
The two files (b0dap30:~belforte/svtvme_fix/temp/*.map) differ
only as indicated above in locations 98-256 (only bins 0-97
are legal values from XFT).</pre>

<!-- Comment: Thu Apr 17 06;41;53 comment by...Stefano -->
<pre>And of course is my fault that when I did the modification
I did not realize that a new CRC was needed in the mapset file,
somehow, since I can not change the DB, I tend to do tests
around this using personal test versions of the mapset. As
Marco pointed out, the ram was never actually rewritten by
the new code at cold start since the read-back CRC was still
matching the value in the mapset file. The only explanation for
what happened yesterday is that XTFA was power cycled between
the stores.</pre>

<!-- Comment: Thu Apr 17 07;23;50 comment by...Stefano -->
Also where I wrote 0xff above, it should have been 0x7f since the
XTFA hardware only passed on 7 bits, that was another bad feature
of old code, using a different value in simulation (0xff) and
data (0x7f).


<!-- Date: Fri Apr 18 19:13:08 2003 -->
I reswapped the svtvme version in the official area. 
Now developmnet is again "development". 
All the crates were rebooted. The new mapset is as before but the crcs were recalculated again with the developmnet version of svtvme. Coldstart is successful
<!-- Author: Marco  -->


<!-- Date: Wed Apr 23 15:17:45 2003 -->
I have switched back off the SVDD readout of Hit Finder 
hf_w01_b2b3.  
<!-- Author: Bill -->


<!-- Date: Mon Apr 28 17:08:09 2003 -->
Hey, I plugged in a GSTM and a VTM, connected them to the 
Hit Finder in slot 6 of the SVT test stand, and I am once 
again able to run the Hit Finder test program!!  Now I can 
try to make the testing of Hit Finders something that can 
be done by a large number of people ... 
  
<!-- Author: Bill -->
<!-- Comment: Mon Apr 28 19;02;24 comment by...Bill -->
Fascinating: it appears that Hit Finder 008 (in tstsvt1 slot 6)
does not have up-to-date firmware.  (Probably same for other
HFs in the test stand.)  When I checked the board against an
obsolete version of the Hit Finder test program, from October
2000, I saw perfect agreement.  When I tried to update the 
firmware in the flash RAM, the FRAM programming code didn't
work, because the board didn't have the version of the 'boot'
program that allows Matt Baumgart's fast FRAM code to run.  I
fixed that, and then loaded the same firmware that is in the
Hit Finders that are in the real SVT crates, and now the board
no longer matches the obsolete test program.  I think this is
progress, except that I now can't find the up-to-date test
program.

<!-- Comment: Mon Apr 28 19;36;52 comment by...Bill -->
Aha, I had deleted the up-to-date test program, but I found it on a backup CD.  (I'll deal with the software management
problem as soon as the firmware management problem is solved.)
The up-to-date HF test program reproduces the behavior of HF
008 when it is loaded from the *.fram files that were used to
load all of the HFs that are in the real SVT crates.  Now I
replace those *.fram files with the output of today's Altera
compilation (same source code, but more recent Altera compiler:
version 10.1), redownload, and everything is still fine.  I also verified that the 'merge' program in the board is the same as today's compiler output.  So
now HF 008, in the test stand, has all programs (boot, merge,
dad, hitman, mop) loaded from the hitfinder CVS repository,
compiled with Max+Plus 10.1, and the behavior agrees with the
"up-to-date" emulator program.


<!-- Comment: Mon Apr 28 19;39;43 comment by...Bill -->
Cycle power ... preceding statement still holds.



<!-- Date: Wed Apr 30 07:02:16 2003 -->
<pre>Paged 4:30 AM because of no or little tracks from wedge 0. 
&lt;ul&gt; 
&lt;li&gt; from spymon histogram --&gt; only one single road out of the HB in wedge 0 &lt;/li&gt; &lt;p&gt; 
&lt;li&gt; from spy buffer dump --&gt; only one single road out of the AMS/AMB &lt;/li&gt;&lt;p&gt; 
&lt;li&gt; asked to power cycle the crate and start a new run &lt;/li&gt;&lt;p&gt; 
&lt;li&gt; problem did not disappear &lt;/li&gt;&lt;p&gt; 
&lt;li&gt; went to B0 and swap AMS &lt;/li&gt;&lt;p&gt; 
&lt;li&gt; timing test points, with all probability, not rewired exactly as they were, anyhow spare AMS does not have test points &lt;/li&gt; &lt;p&gt; 
&lt;li&gt; Data were stopped somewhere in SVT, did not reach the final mergers, until I pulled some of the timing test point.....&lt;/li&gt;&lt;p&gt; 
&lt;li&gt; unfortunately as data taking resumed the problem with wedge 0 is still with us&lt;li&gt;&lt;p&gt; 
&lt;li&gt; for now continue running like this, we will run board diagnostic as soon as a possible&lt;/li&gt;  
&lt;/ul&gt;</pre>
<!-- Author: Marco -->
<!-- Comment: Wed Apr 30 07;39;54 comment by...Stefano & Marco -->
Marco e-mailed me and I called back. We ran ~cdf_svt/tools/am_test/am_test_vme_linux on AMBorads
of wedge0:
<ul>
<li> AMB 0 : OK
<li> AMB 1 : badly fails. This is AMB serial 28. See ~cdf_svt/tools/am_test/logfiles/amv28030430072201.log
</ul>
Marco is swapping AMB 1 (b0svt00/slot10) with a test stand one.


<!-- Comment: Wed Apr 30 07;45;08 comment by...Stefano & Marco -->
Marco e-mailed me and I called back. We ran ~cdf_svt/tools/am_test/am_test_vme_linux on AMBorads
of wedge0:
<ul>
<li> AMB 0 : OK
<li> AMB 1 : badly fails. This is AMB serial 28. See ~cdf_svt/tools/am_test/logfiles/amv28030430072201.log
</ul>
Marco is swapping AMB 1 (b0svt00/slot10) with a test stand one.


<!-- Comment: Wed Apr 30 07;55;18 comment by...Marco  -->
<pre>I swapped AMB 28 with AMB 05 from the test stand, and run some event with hw=fakehits. Attached later a Wedge vs Barrel plot 
that tells that wedge 0 tracks should be recovered now.

I also put back in the AMS with the timing test point (AMS 16).

In the test stand I'll put the AMS 10 and the presumably bad AMB 28 for further diagnostic by the hadrware experts.</pre>


<!-- Comment: Wed Apr 30 07;58;41 comment by...Stefano -->
<table border=0><td><tr><td bgcolor=#e0e030>It would be good to run am_test_vme_linux on the new
board whenever an AMB is swapped in the crate. It has the very good feature of saving a logfile documenting which board goes in, and that it passes (if it does) minimal diagnostics.</td></tr></td></table>
<!-- Comment: Wed Apr 30 08;43;52 comment by...Stefano -->
<pre>I just ran am-test_vme_linux on the bad AMBoard (serial 28)
which is now in test stand slot 10. It still fails with same
errors as before. There is therefore hope that the problem can be
tracked down and fixed.</pre>
<!-- Date: Wed Apr 30 07:58:21 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-94&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-94  width='300' align='top'></td><td>Wedge vs barrel map with the new AMB b0svt00/slot10 using fakehits.Wedge 0 is recovered. The extra holes are caused by  old data (sith missing silicon) used as input for the test. Probably we need to update fakehits data....</a></td></tr></table>
<!-- Author: Marco  -->




<!-- Date: Thu May 1 18:11:16 2003 -->
I imported offline svtsim Hit Finder emulation into svtvme, so 
that I can integrate Hit Finder test software into the svtvme 
package.  I committed and updated.  I had to change 'b0dap32' to 
'b0dap30' in ~cdf_svt/svtvme_update_k5, because the VxWorks 
compiler didn't seem to work anymore on b0dap32.  
<!-- Author: Bill -->
<!-- Comment: Fri May  2 16;21;43 comment by...Stefano -->
I wander why the compilation was done on b0dap32 ... maybe you meant b0dau30 (the SGI).

<!-- Comment: Fri May  2 21;36;05 comment by...Bill -->
<pre>No, I meant b0dap32:

ksu cdf_svt -e /usr/krb5/bin/rsh -f b0dap30 source svtvme_update_linux.csh

this used to say b0dap32.
</pre>

<!-- Comment: Fri May  2 21;36;28 comment by...b -->
<pre>it's ~cdf_svt/svtvme_update_k5
</pre>


<!-- Comment: Fri May 16 04;32;28 comment by...Stefano -->
Definitely b0dap30 is right... I fixed this in the CVS copy as well (svtvme/test)
<!-- Date: Fri May 2 21:37:38 2003 -->
We just updated svtvme_fer.c to propagate patternCenter from 
the mapset into svtvme_patternCenter[] on the crate CPU, for 
Luciano.  Next, Marco will propgate this information into the 
beam fit messages.   The numbers are now in the latest .mapset 
file.  
<!-- Author: Roberto and Bill -->
<!-- Comment: Sat May  3 17;19;00 comment by...Bill -->
By the way, the svtvme library has been updated quite a bit
lately, as I integrate hit finder test code into the library.
So beware, Marco, that you will probably have to reboot the
crates if you want to reload svtspymon to pass the patternCenter
data to Luciano.



<!-- Date: Wed May 14 16:46:13 2003 -->
<pre>XTFA saga 
Marco tries to test low pt track removal and fails (see yesterda's 
evening shift log and my entry in owl, and more on day). 
Now Marco dumped XTFA spy and they are OK, so the test was flawed 
(may fault, I guess) 
For history, here is how to look at those dumps. 
Spy dump files are in b0dap30:~rescigno and are 
 XTFA_TRK.dat and XTFA_OUT.dat 
 
you need to add ~belforte/bin to the path 
 
then the TRK (XTF input) is easy: 
belforte@b0dap30/~rescigno#24&gt; head -25 XTFA_TRK.dat | xtrp_dump 
Word: 32302a: XTRP phi=  42=0.114534 (w: 0 mw:  5 mp:2) Ptbin= 35 Pt=- 2.12 iso/shrt=0/1 
Word: 33c03b: XTRP phi=  59=0.160893 (w: 0 mw:  7 mp:3) Ptbin= 60 Pt=+ 2.12 iso/shrt=0/1 
Word: 28914e: XTRP phi= 334=0.910817 (w: 1 mw: 41 mp:6) Ptbin=  9 Pt=- 2.13 iso/shrt=1/0 
Word: 2d2359: XTRP phi= 857=2.337036 (w: 4 mw:107 mp:1) Ptbin= 82 Pt=+ 2.59 iso/shrt=1/0 
Word: 2dc8b5: XTRP phi=2229=6.078475 (w:11 mw:278 mp:5) Ptbin= 92 Pt=+ 1.68 iso/shrt=1/0 
Word: 33f8ba: XTRP phi=2234=6.092110 (w:11 mw:279 mp:2) Ptbin= 63 Pt=+ 1.57 iso/shrt=0/1 
Word: 600540 : End Event # 40 hex =  64 dec ERRORS: LS 
                    L2buff = 0  L1bits = 00 
Word: 2d7283: XTRP phi= 643=1.753459 (w: 3 mw: 80 mp:3) Ptbin= 87 Pt=+ 2.04 iso/shrt=1/0 
Word: 2d047c: XTRP phi=1148=3.130592 (w: 5 mw:143 mp:4) Ptbin= 80 Pt=+ 2.91 iso/shrt=1/0 
Word: 60057d : End Event # 7d hex = 125 dec ERRORS: LS 
                    L2buff = 0  L1bits = 00 
Word: 2d61a9: XTRP phi= 425=1.158974 (w: 2 mw: 53 mp:1) Ptbin= 86 Pt=+ 2.13 iso/shrt=1/0 
Word: 288879: XTRP phi=2169=5.914855 (w:11 mw:271 mp:1) Ptbin=  8 Pt=- 2.04 iso/shrt=1/0 
Word: 60041b : End Event # 1b hex =  27 dec ERRORS: LS 
                    L2buff = 0  L1bits = 00 
Word: 2da2f1: XTRP phi= 753=2.053428 (w: 3 mw: 94 mp:1) Ptbin= 90 Pt=+ 1.81 iso/shrt=1/0 
Word: 281353: XTRP phi= 851=2.320674 (w: 4 mw:106 mp:3) Ptbin=  1 Pt=- 1.57 iso/shrt=1/0 
Word: 29b3ba: XTRP phi= 954=2.601555 (w: 4 mw:119 mp:2) Ptbin= 27 Pt=- 4.68 iso/shrt=1/0 
Word: 2ce51c: XTRP phi=1308=3.566911 (w: 6 mw:163 mp:4) Ptbin= 78 Pt=+ 3.15 iso/shrt=1/0 
Word: 600558 : End Event # 58 hex =  88 dec ERRORS: LS 
                    L2buff = 0  L1bits = 00 
Word: 28006d: XTRP phi= 109=0.297243 (w: 0 mw: 13 mp:5) Ptbin=  0 Pt=- 1.52 iso/shrt=1/0 
Word: 2d32ca: XTRP phi= 714=1.947075 (w: 3 mw: 89 mp:2) Ptbin= 83 Pt=+ 2.46 iso/shrt=1/0 
Word: 283308: XTRP phi= 776=2.116149 (w: 4 mw: 97 mp:0) Ptbin=  3 Pt=- 1.68 iso/shrt=1/0 
Word: 2d94b1: XTRP phi=1201=3.275123 (w: 6 mw:150 mp:1) Ptbin= 89 Pt=+ 1.88 iso/shrt=1/0 
Word: 280571: XTRP phi=1393=3.798706 (w: 7 mw:174 mp:1) Ptbin=  0 Pt=- 1.52 iso/shrt=1/0 
Word: 2d7749: XTRP phi=1865=5.085848 (w: 9 mw:233 mp:1) Ptbin= 87 Pt=+ 2.04 iso/shrt=1/0 
Word: 600595 : End Event # 95 hex = 149 dec ERRORS: LS 
                    L2buff = 0  L1bits = 00 
 
The OUT is tricky because there are enable bits at odd addresses 
and data at even ones (not, first word is address 0, so it is even). 
Here's the trick, suppress enable with some grep, use 
hit_dump, and then the magic: tracks suppressed by XTFA appear 
in the dump with curvature = 0. Because of enable, and because 
each xtrp work makes 2 words on xtf output, the first 25 data words 
in input are 65 words in output spy (to find this I piped the *dump 
output to "grep End" and looked for matching EndEvent tag sequence: 
 
belforte@b0dap30/~rescigno#24&gt; head -65 XTFA_OUT.dat | grep -v fff | grep -v 0000 | hit_dump 
Word: 1402a0 : XTF HIT: l=5 SuperStripAdd=002a hex  
Word: 30002a : XTRP: phi=  42 (wedge:  5 mini-phi:2) curvature=-  0 iso/eta=0/1 
Word: 1403b0 : XTF HIT: l=5 SuperStripAdd=003b hex  
Word: 30003b : XTRP: phi=  59 (wedge:  7 mini-phi:3) curvature=-  0 iso/eta=0/1 
Word: 141710 : XTF HIT: l=5 SuperStripAdd=0171 hex  
Word: 2ed14e : XTRP: phi= 334 (wedge: 41 mini-phi:6) curvature=-109 iso/eta=1/0 
Word: 1433d0 : XTF HIT: l=5 SuperStripAdd=033d hex  
Word: 2a5359 : XTRP: phi= 857 (wedge:107 mini-phi:1) curvature=- 37 iso/eta=1/0 
Word: 148b50 : XTF HIT: l=5 SuperStripAdd=08b5 hex  
Word: 2808b5 : XTRP: phi=2229 (wedge:278 mini-phi:5) curvature=-  0 iso/eta=1/0 
Word: 148ba0 : XTF HIT: l=5 SuperStripAdd=08ba hex  
Word: 3008ba : XTRP: phi=2234 (wedge:279 mini-phi:2) curvature=-  0 iso/eta=0/1 
Word: 620440 : End Event # 40 hex =  64 dec ERRORS: LS 
                    L2buff = 0  L1bits = 01 
Word: 1425f0 : XTF HIT: l=5 SuperStripAdd=025f hex  
Word: 2af283 : XTRP: phi= 643 (wedge: 80 mini-phi:3) curvature=- 47 iso/eta=1/0 
Word: 144630 : XTF HIT: l=5 SuperStripAdd=0463 hex  
Word: 2a147c : XTRP: phi=1148 (wedge:143 mini-phi:4) curvature=- 33 iso/eta=1/0 
Word: 62047d : End Event # 7d hex = 125 dec ERRORS: LS 
                    L2buff = 0  L1bits = 01 
Word: 141860 : XTF HIT: l=5 SuperStripAdd=0186 hex  
Word: 2ad1a9 : XTRP: phi= 425 (wedge: 53 mini-phi:1) curvature=- 45 iso/eta=1/0 
Word: 1489d0 : XTF HIT: l=5 SuperStripAdd=089d hex  
Word: 2ef879 : XTRP: phi=2169 (wedge:271 mini-phi:1) curvature=-111 iso/eta=1/0 
Word: 62041b : End Event # 1b hex =  27 dec ERRORS: LS 
                    L2buff = 0  L1bits = 01 
Word: 142f10 : XTF HIT: l=5 SuperStripAdd=02f1 hex  
Word: 2802f1 : XTRP: phi= 753 (wedge: 94 mini-phi:1) curvature=-  0 iso/eta=1/0 
Word: 143530 : XTF HIT: l=5 SuperStripAdd=0353 hex  
Word: 280353 : XTRP: phi= 851 (wedge:106 mini-phi:3) curvature=-  0 iso/eta=1/0 
Word: 143ca0 : XTF HIT: l=5 SuperStripAdd=03ca hex  
Word: 2d53ba : XTRP: phi= 954 (wedge:119 mini-phi:2) curvature=- 85 iso/eta=1/0 
Word: 145040 : XTF HIT: l=5 SuperStripAdd=0504 hex  
Word: 29f51c : XTRP: phi=1308 (wedge:163 mini-phi:4) curvature=- 31 iso/eta=1/0 
Word: 620458 : End Event # 58 hex =  88 dec ERRORS: LS 
                    L2buff = 0  L1bits = 01 
Word: 1406d0 : XTF HIT: l=5 SuperStripAdd=006d hex  
 
Note that some track is suppressed becasue is 3-segment (short), 
this is flagged by eta=1 i.e. iso=0, some track has iso=1 and 
eta=0 (eta bit set means high eta, i.e. short, and xft in the 
end found no better way to say isolated then to use non-short 
using iso to mean "good, high quality) but is still suppressed 
beacuse of Pt bin (in xtrp dump) in the diallowed (&lt;8) range. 
</pre>
<!-- Author: Stefano -->
<!-- Comment: Wed May 14 16;55;45 comment by...Stefano -->
<pre>Before you ask, yes, my hit_dump program has a small bug and prints
out the wrong sign for the curvature of layer 5 hits. tomorrow I
will fix it. and yes, there are a lot of misspells. If you find the
sign error, you probably found them also.</pre>


<!-- Date: Thu May 15 03:40:42 2003 -->
<pre>Q: how do we test low pt XFT track removal? 
A: do *NOT* uset fakehits_SB.hwset 
   I found out why it did not work, I had made a little mess when 
   extracting from the 4/5 run data files to be used as fakedata 
   and in the current setup the "wedge" hit finders insted of sending 
   SVX hits from barrels 0-5 send: 
    hf00_0: barrel 2-3 
    hf00_1: barrel 4-5 
    hf00_2: XTF output 
   all other wedges only see EndEvents (I had only extracted data 
   from wedge 0) 
   so the original XTF track list (without any cut) is sent anyhow 
   to the svt core boards.. reagardless of what XTFA does, exactely 
   as Marco found. 
   Of course there is a reason for my being confused (there is a pattern 
   there) besides having done this in owl shift, it had been discussed 
   by me and Bill, and we had agreeded already weeks ago that he is right and 
   I was wrong, but once I understood I forgot to go back and check my 
   fakehits. I will... sometimes... probably in 2 weeks, again while on shift. 
I am pasting this in the SVT e-log, as a permanent caveat about using 
this particular hwset.</pre>
<!-- Author: Stefano -->


<!-- Date: Thu May 15 23:57:23 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-95&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-95  width='300' align='top'></td><td>wedge 8 road id . What is the hole at the right end of the histo?</a></td></tr></table>
<!-- Author: Marco  -->
<!-- Comment: Fri May 16 04;35;24 comment by...Stefano -->
<table border=0><td><tr><td bgcolor=#e0e030>Broken amchip ? Just the last one ? Odd... but sort of
looks like 1/128 of channels are missing.
Is HB_ROAD_SPY the same ? Or AMS_OUT ..
I suggest running am_vme_test_linux in between stores.</td></tr></td></table>

<!-- Comment: Tue May 20 16;44;56 comment by...Bill -->
It's the 3/3 patterns using less than the full AMboard space.



<!-- Date: Tue May 20 16:47:18 2003 -->
<p> 
tf_w07 fails cold start with error writing memry TF0cf1. 
Seems to have been brought on by rack power failure earlier 
today?  Stefano is heading over to take a look. 
<p> 
By the way, we still seem to have the irritating 
problem that when the cold start fails, it crashes the  
Messenger task.  I tried once, unsuccessfully, to track this 
down.  I think Marco and Arnd have also tried, unsuccessfully. 
Maybe time for a fresh pair of eyes? 
<p>
<!-- Author: Bill -->
<!-- Comment: Tue May 20 17;03;21 comment by...Stefano -->
<pre>There is an entry by Bill Badgett in the shift e-log about the fer messenger problem. I leave it to moe expert eyes/hands to understand it.</pre>

<!-- Comment: Tue May 20 17;10;17 comment by...Stefano -->
<pre>And this is what Bill Badgett says:

A side effect of the errors is that 
the fer Messenger task crashes after 
2 or 3 error messages.  SVT should 
recompile their code to resyunc with 
fer.
</pre>


<!-- Comment: Wed May 21 08;53;03 comment by...Stefano -->
Yesterday night I recompiled svtvme development from CVS head and rebooted all SVT crates, so we should be running in sync. with new fer Messenger header files.
<!-- Date: Tue May 20 17:12:35 2003 -->
<pre>OK, I can reproduce the error at cold start: 
 
tf(slot21,tf_w07): mk=tf_w07, tf=0x74724e8 
checkMemoryFragment: nerr=150 
FER_E_SVT, writeMap(tf_w07/TF0cf1): checkMemoryFragment mismatch (nerr=150) 
 
FER_E_SVT, tf(slot21,tf_w07): Coeff F0 C1 map write failed 
 
  svtvme_tf_coldstart returns -200 
Cannot configure readout - check readout list. 
Readout process not started. Error status: 1 
Error Processing Readout List ! 
Sent ack to Run Control: 1 ERROR ERROR  
%FER-E-SVT, writeMap(tf_w07/TF0cf1): checkMemoryFragment mismatch  
%FER-E-SVT, (nerr=150) 
 
%FER-E-SVT, tf(slot21,tf_w07): Coeff F0 C1 map write failed 
 
0x7b85628 (Messenger): memPartFree: invalid block 0x74f4da8 in partition 0x2ded3 
4. 
</pre>
<!-- Author: Stefano -->
<!-- Comment: Tue May 20 17;19;03 comment by...Stefano -->
<pre>Tried to reseat TF in slot 21: it worked !!
(thanks Bill...)
tf(slot21,tf_w07): mk=tf_w07, tf=0x74725b8
  tf_w07:w07_crcTFaddr  2932381494 (2932381494) 131072 bytes written
  tf_w07:w07_crcTFssx0  1650348318 (1650348318) 131072 bytes written
  tf_w07:w07_crcTF0cf1  4130074005 (4130074005) 1024 bytes written
  tf_w07:w07_crcTF1cf1  2031280821 (2031280821) 1024 bytes written
  tf_w07:w07_crcTF2cf1  1032546974 (1032546974) 1024 bytes written
  tf_w07:w07_crcTF3cf1  4023249373 (4023249373) 1024 bytes written
  tf_w07:w07_crcTF4cf1  2545661729 (2545661729) 1024 bytes written
  tf_w07:w07_crcTF5cf1  2867586623 (2867586623) 1024 bytes written
  tf_w07:w07_crcTF0cf2  972770672  (972770672) 1024 bytes written
  tf_w07:w07_crcTF1cf2  550947998  (550947998) 1024 bytes written
  tf_w07:w07_crcTF2cf2  3425513013 (3425513013) 1024 bytes written
  tf_w07:w07_crcTF3cf2  621176099  (621176099) 1024 bytes written
  tf_w07:w07_crcTF4cf2  129609547  (129609547) 1024 bytes written
  tf_w07:w07_crcTF5cf2  3701335574 (3701335574) 1024 bytes written
  tf_w07:w07_crcTF0cf3  441935475  (441935475) 1024 bytes written
  tf_w07:w07_crcTF3cf3  1455044883 (1455044883) 1024 bytes written
  tf_w07:w07_crcTF4cf3  1264207134 (1264207134) 1024 bytes written
  tf_w07:w07_crcTF5cf3  1121920894 (1121920894) 1024 bytes written
  tf_w07:w07_crcTFshft  4228834291 (4228834291) 24 bytes written
  tf_w07:w07_crcTFchi2  1678835870 (1678835870) 256 bytes written
</pre>

<!-- Comment: Tue May 20 17;21;30 comment by...Stefano -->
<pre>I repeated cold start (now called CONFIG) from run_control a few times. All OK.</pre>


<!-- Comment: Tue May 20 17;55;21 comment by...Bill -->
It's really interesting that power-cycling that crate didn't
make the problem go away (and didn't make it happen in slot
12), but reseating the board in slot 21 did make the problem
go away.  Maybe this will provide a useful hint if anyone 
ever tries to track this down.

<!-- Comment: Tue May 20 18;20;45 comment by...Stefano -->
<pre>I suspect it has to do with a little time difference in 3V and 5V coming up, maybe some critical TF chip is not well protected against one of the two voltage missing and some slowly drifting input signal cause some internal FSM to go into an illegal state.
Just a theory.</pre>
<!-- Date: Tue May 20 17:40:35 2003 -->
<pre>I tested with fakehist. CAn see tracks in OSPY of TF b0svt03/21 i.e. wedge 7. All OK.</pre>
<!-- Author: Stefano -->


<!-- Date: Tue May 20 17:42:18 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-96&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-96  width='300' align='top'></td><td>From SVTSPYMON, Tracks in wedge 7.</a></td></tr></table>
<!-- Author: Stefano -->
<!-- Comment: Tue May 20 17;45;07 comment by...Stefano -->
N.B. I used RC configuration SVT_500HZ and in there changed SVTmode from hw=500hz to hw=fakehits. It looks like we do not have a RC config ready at hand for doing fakehits... should fix this.





<!-- Date: Fri May 23 10:04:02 2003 -->
<b>AM Boards</B><br> 
The day before yesterday, to do my AMS tests I needed a working test stand.<br> 
I have put a good AM Board from spare cabinet (serial #2) 
into test stand slot 10 (AMB-1) so that the test stand now works. 
 
<p> 
The AM Board that was in the test stand before (serial #28), which is the one that was removed from the trigger crate some weeks ago, still has the same problems and is now in the spare 
cabinet with a label attached.  
<!-- Author: Stefano -->