(r61) AMC13DebugLog < Main

Tags: view all tags
Please log AMC13 test activity below, blog style (new entries at top)

---+++ 2013-06-19, dzou, hazen

   * Move probe to CLK output of ADN2814 CDS
   * Data on Sheet 6 of: [[http://ohm.bu.edu/~dzou/ClockPhaseShift.xlsx][ClockPhaseShift.xlsx]] 
   * Height of roughly 200 ps
Plot of clock phase at various power off times

<img src="http://ohm.bu.edu/~dzou/ClockPhase_2013-06-19.png" width="600">

   * Study datasheets for tempco or phase/delay specs
      * [[http://ohm.bu.edu/~hazen/DataSheets/AMD/ADN2814.pdf][ADN2814]]:  no obvious information, but it's pretty long and detailed so I may have missed something
      * [[http://ohm.bu.edu/~hazen/DataSheets/Micrel/sy89832u.pdf][SY89832]]:  300-500ps delay; 200ps risetime; no tempco information
      * [[http://ohm.bu.edu/~hazen/DataSheets/Micrel/sy89872u.pdf][SY89872]]:  450-700ps delay; 130ps risetime.  There is a prop delay vs temp plot; 25ps over 60 deg C more or less linear (0.42ps/deg C)
      * [[http://ohm.bu.edu/~hazen/DataSheets/TI/ds91m125.pdf][DS91M125]]:  3-8ns delay;  risetime 2ns per M-LVDS spec.  There is a prop delay vs temp plot; slope is 10ps/deg C

---+++ 2013-06-17, dzou, hazen

   * Move probe to LVDS pair between U3 and U4 on T1 (Fanout and divider chip) and repeat measurements.
   * Typical exponential behavior of phase shift. Height of roughly 200 ps (after power off of 5 mins).
   * Data in Sheet 5 of: [[http://ohm.bu.edu/~dzou/ClockPhaseShift.xlsx][ClockPhaseShift.xlsx]] 

 Plot of clock phase at various power off times

<img src="http://ohm.bu.edu/~dzou/ClockPhase_2013-06-17.png" width="600">

---+++ 2013-06-14 dzou, dickens
   * Update TTT firmware and tested range of TTT SN 2: Found similar results as 2013-06-13 entry. AMC13 clock stops working at somewhere between 80 and 90 MHz. Lock lost at around 120 MHz.

   * Continuing Clock Phase Shift testing:
      * Placed probe in clock path prior to the m-LVDS (T2 board -- U25 input @ R18) on SN 33
      * Observed a unexpected phase behavior when changing amplitude of AWG: 
         * Shifting from 900mV peak to peak to 600mV cause the signals (AWG and probe) to go out of phase and stay there even after returning to 900mV. (delay of roughly 9.58 ns)
         * Shifting back down to 600 mV puts it back in phase again. (delay of roughly 3.38 ns)
         * (will include screen shots if necessary)
      * Continued testing with settings described in 2013-06-11 entry
      * Data in Sheet 3 of:  [[http://ohm.bu.edu/~dzou/ClockPhaseShift.xlsx][ClockPhaseShift.xlsx]] 
Plot of clock phase at various power off times

<img src="http://ohm.bu.edu/~dzou/ClockPhase_2013-06-14.png" width="600">

   * Moved probe to output of SFP receiver for TTC input (two vias next to U2 on T1).
   * Repeat power-cycle tests
   * See essentially *no shift* with power cycling

---+++ 2013-06-13 dickens
   * AMC13XG and TTT frequency range tests:
      * Found the upper limit of clock frequency manageable by AMC13XG to be 85.1 MHz.  Periodic "gaps" of constant amplitude voltage appear in the AMC13XG signal thereafter. These gaps become more frequent as the clock frequency increases. 
         * Setup is identical to setup notated by "2013-06-11 dzou, hazen," but with variable frequency outputted by the AWG.
      * Found the upper limit of clock frequency manageable by TTT to be 124 MHz, which is where jitters begin. Jitters become more pronounced around 125 MHz and the TTT loses lock by 125.7 MHz. 
         * The setup for this test maintains all connections of the previous test, but for one exception. The B channel of the TTT is connected to itself, creating a feedback loop, rather than connected to the AMC13 TTC port by 4ft fiber.

---+++ 2013-06-12 dzou
   * Additional test runs made for investigating clock phase shift:
      * Made initial test run after over night power off  (~16 hours) 
      * Made three test runs w/ 10s power off and then one test run for various times of power off: 1, 2, 5, 10 mins (see below).
      * Data in Sheet 2 of:  [[http://ohm.bu.edu/~dzou/ClockPhaseShift.xlsx][ClockPhaseShift.xlsx]] 
      * [[http://ohm.bu.edu/~dzou/ClockPhaseShift.pdf][ClockPhaseShift.pdf]] (pg 3 and 4)
   * Observations not included in test runs: 
      * Phase shift after 1 hour of power on: 4.524
Plot of clock phase at various power off times

<img src="http://ohm.bu.edu/~dzou/ClockPhaseShift_2013-06-12.png" width="600">

---+++ 2013-06-11 dzou, hazen

   * Measuring TTC Clock Phase Shift - Notes on Setup:
      * Using Agilent AWG 40 MHz 900mV peak to peak output as external clock
      * AWG connect by 2 ft onto T on channel 4 of oscilloscope (LeCroy 725 ZI 2.5 GHz)
      * 4ft long cable from T to external clock to TTT
      * D310 differential probe soldered to FClkA  on receiver AMC13 at backplane connector w/ 100 ohm between the pair
      * AMC13 receiving clock is in slot 8 (SN 43)
      * SN 40 in AMC13 with 4ft duplex fiber to B chann of TTT
 
   * Saved oscilloscope screen shot clocks2.jpg 4.47 ns (after being turned on for a while, before any power cycling)
   * Cycling handle power of AMC13 that is providing clock (SN 40) - power down for 30 secs (phase at 4.34 ns) (clocks3.jpg)

   * [[http://ohm.bu.edu/~dzou/ClockPhaseShift.xlsx][ClockPhaseShift.xlsx]] (Sheet 1)
   * [[http://ohm.bu.edu/~dzou/ClockPhaseShiftPrelimTests.pdf][ClockPhaseShiftPrelimTests.pdf]]

<img src="http://joule.bu.edu/~hazen/CMS/AMC13DebugData/2013-06-11_clock_plot1.gif">

Plot of a few test runs.  Results are similar in magnitude to those seen at CERN.

---+++ 2013-06-06 dzou

   * Updates to the T1 firmware version 0x8a seems to fix the errors from 2013-06-04 debug log. Production test can run consecutively on the same board w/o a power reset w/ 0x8a.
   * The board currently in slot AMC13 seems to be SN 40 but is labelled w/ a front panel w/ SN 37. This should be corrected.

---+++ 2013-06-04 David, Eric, Ben

   * Trying to test S/N 34 in slot 4.  Observe that after running Charlie's production test that we can't run it again, and in fact even after power cycling can't ping T1.  Try eeperase and mreset on the MMC, still no go!  
   * Try the same treatment on S/N 39.  Both FPGAs still respond to ping.  But the test fails in a different way the 2nd time.
   * Mysteries abound.  Could be hardware, MMC or production test software or a combination of them.  In any case shipping anything under these conditions seems like a poor idea.
   * production test seems to not work twice in a row without spitting errors, but seems to work after a handle power reset. But an error will often occur on the first attempt if you do not wait sufficiently long for the AMC13 to boot up (2 min was sufficient).
   * Had similar problems while trying to program the FPGA firmware for S/N 44 in slot 4. After programming the FPGA's and loading, continued to get T1 not found at this location error. Note that prior to this, we were able to program S/N 43 in slot 3 with no problems. 
   * Errors arise while trying to read from the flash. T1 Error : IPbus Transaction failure during write to register 'FLASH_CMD' or T2 Error : IPbus Transaction failure during write to register 'FLASH_WBUF'
   * Trying to program S/N 45 in slot 3 using 0x89. After programming FPGA, T1 is unreachable. Revert to T1 FPGA of 0x87 and T1 is working again.


---+++ 2013-05-30 hazen

   * NAT MCH in crate seems to have died!  Symptom was that the Ethernet switch worked (IPBus access to the AMC modules was fine) but couldn't access the MCH by telnet, and the LAN-to-ipmi bridge didn't work.  Also, couldn't connect by serial cable to the WinXP machine.
   * Replaced with spare.  MCH I/P is now 192.168.1.41.  Works.  However, the serial access using PUTTY on WinXP machine still doesn't work. Can talk to it fine using minicom on cms2 with port /dev/ttyACM0.  Go figure.


---+++ 2013-05-10 hill and wu

Edit by David Zou on 2013-06-07:
The IP address has been recently changed so if you use any of the IPMI commands described below, make sure to use the new IP address:
<verbatim>
192.168.1.41
</verbatim>
MMC IPMI commands for reading an AMC13 in slot 3 (IPMB 0x76)
   * *Read Spartan Address*
   <verbatim>
   ipmitool -H 192.168.1.11 -U '' -P '' -T 0x82 -b 7 -t 0x76 raw 0x32 0x34 0 0 0 20
   </verbatim>
   * *Read Virtex Address*
   <verbatim>
   ipmitool -H 192.168.1.11 -U '' -P '' -T 0x82 -b 7 -t 0x76 raw 0x32 0x34 1 0 0 20
   </verbatim>
   * *Write IP Address 192.168.1.100 to SPI Port 0*
   <verbatim>
   ipmitool -H 192.168.1.11 -U '' -P '' -T 0x82 -b 7 -t 0x76 raw 0x32 0x33 0 0 0 11 03 0xff 0xff 00 00 0xc0 0xa8 0x01 0x64 0x00 0x00
   </verbatim>
   * *Write IP Address 192.168.1.101 to SPI Port 1*
   <verbatim>
   ipmitool -H 192.168.1.11 -U '' -P '' -T 0x82 -b 7 -t 0x76 raw 0x32 0x33 1 0 0 11 03 0xff 0xff 00 00 0xc0 0xa8 0x01 0x65 0x00 0x00
   </verbatim>
   * *Configure Spartan FPGA from SPI 0*
   <verbatim>
   ipmitool -H 192.168.1.11 -U '' -P '' -T 0x82 -b 7 -t 0x76 raw 0x32 0x32 0 0x22
   </verbatim>
   * *Configure Virtex FPGA from SPI 1*
   <verbatim>
   ipmitool -H 192.168.1.11 -U '' -P '' -T 0x82 -b 7 -t 0x76 raw 0x32 0x32 1 0x22
   </verbatim>

---+++ 2013-05-03 hill

Procedure for initializing the DAQ Path on the uHTR board and getting it to send data for a module in slot #2 in the uTCA crate:
<verbatim>
$ cd hcal/hcalUHTR
$ ./bin/linux/x86_64_slc5/uHTRtool.exe 192.168.115.8
 (0) IP[192.168.115.8]  Type: UHTR 
 ID of uHTR (-1 for exiting the tool) :: 
 Front Firmware revision : (00) 00.04.13 
 Back Firmware revision : (00) 00.06.10 
  Clock expected at    25.0000 MHz :    25.0000 MHz (front)     25.0000 MHz (back) 
  Clock expected at   100.0000 MHz :   100.0000 MHz (front)    100.0000 MHz (back) 
  Clock expected at    40.0800 MHz :    39.9999 MHz (front)     39.9999 MHz (back) 
  Clock expected at    80.1600 MHz :    79.9998 MHz (front)     79.9998 MHz (back) 
  Clock expected at   120.2400 MHz :   119.9997 MHz (front)    119.9997 MHz (back) 
  Clock expected at   160.3200 MHz :   159.9997 MHz (front)    159.9997 MHz (back) 
  Clock expected at   240.4800 MHz :   239.9995 MHz (front)    239.9995 MHz (back) 
  Clock expected at   320.6400 MHz :   319.9994 MHz (front)    319.9993 MHz (back) 
  Clock expected at    11.0000 kHz :    11.2230 kHz (front)     11.2230 kHz (back) 
  Clock expected at     0.1100 kHz :     0.0000 kHz (front)      0.0000 kHz (back) 
  Clock expected at    40.0800 MHz :    39.9999 MHz (front)     39.9999 MHz (back) 
  Clock expected at    40.0800 MHz :    39.9999 MHz (front)     39.9999 MHz (back) 
  Clock expected at   240.4800 MHz :     0.0000 MHz (front)     56.7837 MHz (back) 



   STATUS       Status summary of the uHTR card
   LINK         Status and control of frontend links
   DTC          Information received from DTC
   CLOCK        Clock module work
   SENSOR       I2C sensors and controls
   TRIG         Trigger-path work
   DAQ          DAQ-path work
   TEST         Functionality tests of uHTR Board
   FLASH        Flash programming and readback menu
   LUMI         LUMI-DAQ work
   EXIT         Exit this tool
 > daq

   STATUS       Status of the DAQ path
   SPY          Read the DAQ path spy
   CTL          Control the DAQ path
   F2B          F2B DAQ Link Operations
   QUIT         Back to top menu
 > ctl

DAQ F2B Links
  0 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  1 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  2 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 9424 (0.000000e+00 Hz)
DAQ Path : ENABLED       ZS(per sample)
   Last EVN: 10   OrN : 2983852  Header Occupancy : 0  (Peak : 1)
   Samples: 10   Presamples : 4  Pipeline Length : 50
   ZS Mask (one means ignore) : 0x   0 
   TP Samples: 14   TP Presamples : 11  
   TP ZS : TP_NZS  
   Module Id : 0 (0x0)   BC Offset : 0


 (1) Set Module Id  (2) Set BC Offset       (3) Set NSAMPLES
 (4) Set PRESAMPLES (5) Set Pipeline Length (6) Set ZS Mask 
 (7) Enable DAQ Path (toggle)   (8) Reset DAQ Path 
 (9) Toggle NZS    (10) Toggle Mark-And-Pass ZS    (11) Toggle ZS Sum-By-Two
 (12) Dump ZS Thresholds   (13) Edit ZS Thresholds   (14) Uniform ZS
 (15) Set TP PRESAMPLES  (16) Set TP SAMPLES
 (17) Toggle ZS for TP (18) Toggle SOI-only for TP

 (  Anything else will just return to the original menu )

Selection :  [-1] 3
  New nsamples :  [10] 10

DAQ F2B Links
  0 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  1 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  2 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 9424 (0.000000e+00 Hz)
DAQ Path : ENABLED       ZS(per sample)
   Last EVN: 10   OrN : 3737623  Header Occupancy : 0  (Peak : 1)
   Samples: 10   Presamples : 4  Pipeline Length : 50
   ZS Mask (one means ignore) : 0x   0 
   TP Samples: 14   TP Presamples : 11  
   TP ZS : TP_NZS  
   Module Id : 0 (0x0)   BC Offset : 0


 (1) Set Module Id  (2) Set BC Offset       (3) Set NSAMPLES
 (4) Set PRESAMPLES (5) Set Pipeline Length (6) Set ZS Mask 
 (7) Enable DAQ Path (toggle)   (8) Reset DAQ Path 
 (9) Toggle NZS    (10) Toggle Mark-And-Pass ZS    (11) Toggle ZS Sum-By-Two
 (12) Dump ZS Thresholds   (13) Edit ZS Thresholds   (14) Uniform ZS
 (15) Set TP PRESAMPLES  (16) Set TP SAMPLES
 (17) Toggle ZS for TP (18) Toggle SOI-only for TP

 (  Anything else will just return to the original menu )

 Selection :  [-1] 4
  New presamples :  [4] 4

DAQ F2B Links
  0 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  1 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  2 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 9424 (0.000000e+00 Hz)
DAQ Path : ENABLED       ZS(per sample)
   Last EVN: 10   OrN : 3803540  Header Occupancy : 0  (Peak : 1)
   Samples: 10   Presamples : 4  Pipeline Length : 50
   ZS Mask (one means ignore) : 0x   0 
   TP Samples: 14   TP Presamples : 11  
   TP ZS : TP_NZS  
   Module Id : 0 (0x0)   BC Offset : 0


 (1) Set Module Id  (2) Set BC Offset       (3) Set NSAMPLES
 (4) Set PRESAMPLES (5) Set Pipeline Length (6) Set ZS Mask 
 (7) Enable DAQ Path (toggle)   (8) Reset DAQ Path 
 (9) Toggle NZS    (10) Toggle Mark-And-Pass ZS    (11) Toggle ZS Sum-By-Two
 (12) Dump ZS Thresholds   (13) Edit ZS Thresholds   (14) Uniform ZS
 (15) Set TP PRESAMPLES  (16) Set TP SAMPLES
 (17) Toggle ZS for TP (18) Toggle SOI-only for TP

 (  Anything else will just return to the original menu )

 Selection :  [-1] 5
  New pipeline length :  [50] 50

DAQ F2B Links
  0 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  1 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  2 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 9424 (0.000000e+00 Hz)
DAQ Path : ENABLED       ZS(per sample)
   Last EVN: 10   OrN : 3842107  Header Occupancy : 0  (Peak : 1)
   Samples: 10   Presamples : 4  Pipeline Length : 50
   ZS Mask (one means ignore) : 0x   0 
   TP Samples: 14   TP Presamples : 11  
   TP ZS : TP_NZS  
   Module Id : 0 (0x0)   BC Offset : 0


 (1) Set Module Id  (2) Set BC Offset       (3) Set NSAMPLES
 (4) Set PRESAMPLES (5) Set Pipeline Length (6) Set ZS Mask 
 (7) Enable DAQ Path (toggle)   (8) Reset DAQ Path 
 (9) Toggle NZS    (10) Toggle Mark-And-Pass ZS    (11) Toggle ZS Sum-By-Two
 (12) Dump ZS Thresholds   (13) Edit ZS Thresholds   (14) Uniform ZS
 (15) Set TP PRESAMPLES  (16) Set TP SAMPLES
 (17) Toggle ZS for TP (18) Toggle SOI-only for TP

 (  Anything else will just return to the original menu )

 Selection :  [-1] 8

DAQ F2B Links
  0 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  1 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 8675 (0.000000e+00 Hz)
  2 : Status = f  Errors = 19349  (0.000000e+00 Hz)  Words = 9424 (0.000000e+00 Hz)
DAQ Path : ENABLED       ZS(per sample)
   Last EVN: 0   OrN : 39  Header Occupancy : 0  (Peak : 0)
   Samples: 10   Presamples : 4  Pipeline Length : 50
   ZS Mask (one means ignore) : 0x   0 
   TP Samples: 14   TP Presamples : 11  
   TP ZS : TP_NZS  
   Module Id : 0 (0x0)   BC Offset : 0


 (1) Set Module Id  (2) Set BC Offset       (3) Set NSAMPLES
 (4) Set PRESAMPLES (5) Set Pipeline Length (6) Set ZS Mask 
 (7) Enable DAQ Path (toggle)   (8) Reset DAQ Path 
 (9) Toggle NZS    (10) Toggle Mark-And-Pass ZS    (11) Toggle ZS Sum-By-Two
 (12) Dump ZS Thresholds   (13) Edit ZS Thresholds   (14) Uniform ZS
 (15) Set TP PRESAMPLES  (16) Set TP SAMPLES
 (17) Toggle ZS for TP (18) Toggle SOI-only for TP

 (  Anything else will just return to the original menu )

 Selection :  [-1] 7
</verbatim>

If you now send L1As to the uHTR, it produces events!  Very good!


---+++ 2013-03-11 hill

Trouble getting the TTCvi to work.  The VME crate had been shut down for at least two weeks prior to this test.  Otherwise, it was never touched...

Procedure which fails:

Reset the Xilinx trigger board
<verbatim>
$ cd source ~/environ.sh (to set the environment)
$ cd ~/TTS_ctrl
$ ./periodic_120hz
Orbit Length:       -o 3563 BX
Trigger Delay:      -d 500 BX
Orbit Count:        -n 0 orbits
Trigger Spacing:    -s 25 BX
Triggers per orbit: -t 1 triggers
Repeat period:      -r 100 orbits
Random threshold:   -p 0 / 65535
TTS latency         -l 0 BXn (0 sec)
TTS sample mask     -m 0
TTC cmd BCN         -w 1000
Allow L1A in gap    -g 0
Trigger rule 1: not enabled
Trigger rule 2: not enabled
Trigger rule 3: not enabled
Trigger rule 4: not enabled
Rule enable mask: 0x0
$ cd ../ttc
$ DCCdiagnose.exe -x setup_ttc.dcc
DCCdiagnose.exe revision 27 Mar 2009
Load TTCvi_base = 0xf10000
Load vme_slot = 0x13
Load log_level = error
Load hal_path = /home/daqowner/dist/hal/hcal/
Load vme_bus = caen:0
Load ttc_bus = caen:0
HAL search path set to /opt/xdaq/hal/hcal/
Overriding default HAL path with /home/daqowner/dist/hal/hcal/ from PROGRAMMER_HAL_PATH
Looking for HAL addresstable files in directory /home/daqowner/dist/hal/hcal/
(change by setting PROGRAMMER_HAL_PATH environment variable)
INFO:  Logger set up
V2718 firmware : 2.00
A2818 firmware : 0.06
VMELibRelease  : 2.30.2
INFO:  busAdapter set up
INFO:  DCC constructed
DCC1 created
INFO:  DCC connected
INFO:  TTCvi set up
DCCdiagnose.exe - dcc->setupHAL()
(/home/daqowner/dist/hal/hcal/DCC_LRB.dat,/home/daqowner/dist/hal/hcal/DCC_LTB.dat,/home/daqowner/dist/hal/hcal/DCC_log12.dat,/home/daqowner/dist/hal/hcal/DCC_log123_conf.dat,/home/daqowner/dist/hal/hcal/DCC_logicboardv4_2c.dat
DCC::initialize()...
DCC::getMainAddressMap()... DCC::getMasterDevice()
DCC revision is 2c36
[Script setup_ttc.dcc start]
#
# DCC script to setup TTCvi
#
    ttc/write 0x82 0xf000	 # reset BGO fifos
    ttc/write 0x80 0xff64        # enable external orbit, disable triggers
    ttc/write 0x92 10            # inhibit 0 delay (250ns)
    ttc/write 0x94 10		 # inhibit 0 duration (250ns)
    ttc/write BData0 0x00800000  # write one word (BCR, cmd=01) to fifo 0
    ttc/write 0x90 0xd           # enable BG0 channel 0
    ttc/cmd 2                    # send ECR
    ttc/cmd 0x28                 # send OCR
    ttc/trig 4			 # disable L1A
TTC L1A source set to 4 (VME)
q
$ DCCdiagnose.exe
>ttc/trig 1
TTC L1A source set to 1 (panel input)
</verbatim>

No triggers are sent, and the TTCvi panel has LEDs lit which I have never seen lit before, namely "L1A Req" (a yellow light) and "Req0" (a red light...this one may have been lit before and I may just not have noticed).

After letting it run for awhile like that, this is what the AMC13 status looks like:

<verbatim>
EVB Counters:  (All 32-bit counters read 0x0)
                   TTC BC0 err [0044]: 00000000 00000014
                      Run time [0048]: 00000008 901aa25a
                    Ready time [004a]: 00000008 901aa258
                     Busy time [004c]: 00000000 00000001
            L1A ovfl warn time [0050]: 00000000 00000001
AMC Counters:
                                       <---Link 00-----> <---Link 01-----> <---Link 02-----> <---Link 03-----> <---Link 04-----> <---Link 05----->
              Single Bit Error [0042]: 00000000 2a969f7d 00000000 010c7ed6 00000000 00000000 00000000 2cfa0526 00000000 1f6064d3 00000000 246de015
               Multi Bit Error [0044]: 00000000 2979f006 00000000 010ceb14 00000000 00000000 00000000 2b92e914 00000000 1c20314c 00000000 22ce9cc2
                        Resend [004a]: 00000000 000034d9 00000000 00000004 00000000 00000000 00000000 0003b62b 00000000 0001c064 00000000 00013702
                    Data Abort [0056]: 00000000 0000018f 00000000 00000000 00000000 00000000 00000000 00005cba 00000000 00000013 00000000 000006a5
                 Counter Abort [0058]: 00000000 0000056f 00000000 0000056f 00000000 00000000 00000000 00005c3a 00000000 0000001c 00000000 000003dd
                     SEQ Abort [0060]: 00000000 00000a23 00000000 00000000 00000000 00000000 00000000 0001026d 00000000 0000004c 00000000 00000d8a
                     CRC Abort [0062]: 00000000 00000a27 00000000 00000000 00000000 00000000 00000000 000104c9 00000000 0000004c 00000000 00000d8a
                   Frame Abort [0064]: 00000000 00000a27 00000000 00000000 00000000 00000000 00000000 000104ca 00000000 0000004c 00000000 00000d8a
                  K Char Abort [0066]: 00000000 000006af 00000000 00000000 00000000 00000000 00000000 0000b1c5 00000000 0000002f 00000000 00000a70


                                       <---Link 06-----> <---Link 07-----> <---Link 08-----> <---Link 09-----> <---Link 10-----> <---Link 11----->
              Single Bit Error [0042]: 00000000 0d36f3be 00000000 274afb1e 00000000 2540bcdb 00000000 26500e4a 00000000 2a4f9392 00000000 1b3271bf
               Multi Bit Error [0044]: 00000000 0c796460 00000000 26120309 00000000 247c3658 00000000 2537700e 00000000 28a7e404 00000000 1b0e5e0e
                        Resend [004a]: 00000000 00000182 00000000 00025f24 00000000 00003199 00000000 000298db 00000000 00015b55 00000000 00005991
                    Data Abort [0056]: 00000000 00000047 00000000 00002d40 00000000 00000100 00000000 0000109d 00000000 000013b7 00000000 000000c0
                 Counter Abort [0058]: 00000000 00000019 00000000 00000789 00000000 000000bd 00000000 0000028c 00000000 00000169 00000000 00000038
                     SEQ Abort [0060]: 00000000 0000008a 00000000 00004003 00000000 000002c5 00000000 00001df4 00000000 000024bb 00000000 00000131
                     CRC Abort [0062]: 00000000 0000008a 00000000 000040f8 00000000 000002c9 00000000 00001df8 00000000 00002714 00000000 00000132
                   Frame Abort [0064]: 00000000 0000008a 00000000 000040f8 00000000 000002c9 00000000 00001df8 00000000 00002714 00000000 00000132
                  K Char Abort [0066]: 00000000 00000060 00000000 0000349b 00000000 000001b9 00000000 000012fe 00000000 000014cd 00000000 000000f5
</verbatim>

Ummmm...I fixed it, I guess.  All I did was leave the system alone for a second to read about TTCvi, and it started working all of a sudden.  Huh.  Well, I'm not complaining!  The LED lighting didn't have anything to do with the problem, apparently.  Perhaps the system needs to take a minute to gather itself after being shut off for awhile.


 

---+++ 2012-11-26, hazen/hill

Changing !VadaTech IP addresses:

   * eth1 (GbE) now 192.168.40.250 change to 192.168.1.2
   * eth0 (10/100) now 192.168.1.252 change 192.168.2.2

<pre>
# net interface 0
export SYSCFG_IFACE0=y
export INTERFACE0="eth0"
export IPADDR0="192.168.2.2"
export NETMASK0="255.255.255.0"
export BROADCAST0="192.168.2.255"
export GATEWAY0="192.168.1.1"
export NAMESERVER0="0.0.0.0"
# net interface 1
export SYSCFG_IFACE1=y
export INTERFACE1="eth1"
export IPADDR1="192.168.1.2"
export NETMASK1="255.255.255.0"
export BROADCAST1="192.168.1.255"
export GATEWAY1="0.0.0.0"
export NAMESERVER1="0.0.0.0"
</pre>
   * After setting this configuration, we are unable to ping the 10/100 port.  We are, however, able to ping the !GbE port and talk to !AMC13s, but not the !mCTR2s.  We suspect that the MMC code for the !mCTR2s is out of date.  Eric is going to contact Tom Gorski on this one.

---+++ 2012-11-21, hill

#VadatechInstallation
Attempting an initial installation of the !VadaTech Commercial MCH card for the uTCA crate.

Procedure:
   1. Install the !VadaTech module in the MCH2
   1. Initial attempt at IPbus-based communication with the !uTCA crate results in successful pinging and control of the AMC13 in MCH1 and also the AMC13 in a non-MCH slot, but unsuccessful pinging of !mCTR2s
   1. Relevant Documents are...
      * [[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDAQFjAA&url=http%3A%2F%2Fjoule.bu.edu%2F~hazen%2FCMS%2FManual%2FUTC001%2FVadaTech%2520MicroTCA%2520MCH%2520Getting%2520Started%2520Guide.pdf&ei=UYSzUK3pIaPm0gGKxYCADA&usg=AFQjCNEghvbbsBZHuAnb3ROth30Suff3gQ&sig2=j4Vf4u4apQGEdsdj3Vspdg][VadaTech microTCA MCH Getting Started Guide]]
      * [[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDMQFjAA&url=http%3A%2F%2Fjoule.bu.edu%2F~hazen%2FCMS%2FManual%2FUTC001%2FVadaTech%2520Gigabit%2520Ethernet%2520Managed%2520Switch%2520Setup.pdf&ei=LoCzUJLsCqLL0AG1o4HoDA&usg=AFQjCNH_-eJTVG2sapwXQWQ0IfC47kls-Q&sig2=q0-l_tJVhcqvpUk0t9Y9fA][VadaTech Gigabit Ethernet Managed Switch Setup]]
      * [[http://www.google.com/urlsa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDoQFjAB&url=http%3A%2F%2Fjoule.bu.edu%2F~hazen%2FCMS%2FManual%2FUTC001%2FVadaTech%2520MCH%2520and%2520AMC229%252010GbE%2520Switch%2520Management%2520CPU%2520Console.pdf&ei=LoCzUJLsCqLL0AG1o4HoDA&usg=AFQjCNHlxN1NEZU7nPIMjXag5i4QNBk_lQ&sig2=9DVoYcd3EO1k-rH6yQBnEg][VadaTech MCH and AMC229 10 GbE Switch Management CPU Console]]
   1. 10/100 Ethernet has the default IP address 192.168.1.252, which conflicts with our IP assignment scheme for the AMC13s. 
   1. According to the 'Getting Started Guide', the default IP address of the !GbE is 192.168.40.250.  Unsuccessful ping to this address.
   1. Run Eric's =pinger.py= to see what I can talk to.  Within the range 192.168.1.255.......1, I can only see the !AMC13s.  This was to check and make sure the !VadaTech MCH card didn't magically take on the same IP address as the NAT MCH card
   1. Despite my not being able to ping the !GbE, I am going to try and connect anyway, as the documentation suggests.  
      <verbatim>
      [cms2] /home/chill90 > ssh root@192.168.40.250
      ssh: connect to host 192.168.40.250 port 22: Connection timed out
      [cms2] /home/chill90 > ssh 192.168.40.250
      ssh: connect to host 192.168.40.250 port 22: Connection timed out
      </verbatim>
      Not surprisingly, no luck here.  I get similar results if I try and access the IP address via a web browser
   1. Next try connecting via the 10/100 Ethernet Port at 192.168.1.252.  This pings successfully!
   1. Eric has now take over.  
   1. !TelNet into the card successfully.
      * => telnet 192.168.1.252=
      * Username: *root*
      * Password: *root*
   1. The HUB card will be running Linux.  The command-line interface is based on the IPMI v2.0.  The procedure to reassign the IP addresses of the ethernet ports is as follows
      1. Open the file =/etc/rc.d/rc.conf= for editing
      1. _net interface 0_ is the 10/100 Ethernet port.  Edit =IPADDR0= and/or =NETMASK0= and/or =BROADCAST0= as desired
      1. _net interface 1_ is the !GbE port.  Edit =IPADDR1= and/or =NETMASK1= and/or =BROADCAST1= as desired
      1. Only __one__ of __either__ =GATEWAY0= or =GATEWAY1= should be set!!  The MCH will use the device with the set 'GATEWAY' value to send traffic to other subnets and networks 
      1. Power cycle the MCH for the changes to take effect 
     
 

---+++ 2012-10-26, hazen

#IPAddressSet

*NOTE:  Don't design any software to use this feature yet.*
Some small details are likely to change, but the concept will remain.

Working on IP address setting by IPMI.  Using Tom's recipe:

<pre>
export IPMITOOLARGS="-H 192.168.1.11 -P \"\" -T 0x82 -B 0 -b 7"

# read Spartan IP address
>  ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x34 0 0 7 4
f6 01 a8 c0

# read Virtex IP address (bus addr byte determined empirically!)
>  ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x34 1 0 7 4
f7 01 a8 c0
</pre>

Changing the address:

<pre>
# set spartan address low byte to 128
> ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x33 0 0 7 1 0x80
# set virtex address low byte to 129
> ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x33 1 0 7 1 0x81

[cms2] /home/hazen > ping 192.168.1.128
PING 192.168.1.128 (192.168.1.128) 56(84) bytes of data.
64 bytes from 192.168.1.128: icmp_seq=1 ttl=64 time=0.240 ms
64 bytes from 192.168.1.128: icmp_seq=2 ttl=64 time=0.060 ms
</pre>

It works!

---+++ 2012-09-28, eric

***This has since been fixed.  There was a discrepancy between our local Makefile and the release Makefile.  

Charlie has complained of ghosts in the machine.
All is OK if I do the following:

   * Goto cms1, run ./periodic_12hz
   * Run DCCdiagnose.exe, ttc/trig 1  (light blinks)
   * Goto AMC13Tool_3 directory, run AMC13Tool
   * do init.amc
   * turn on triggers for a while

Attempting to reproduce the EvN mismatch symptom described by Jeremy so Wu can
look at it by remote control.  First, update mCTR2s to firmware 0.5.20.

my AMC13Tool has dependency problems.  Create a directory AMC13Tool_4 and
copy Charlie's 11_5_5 exe and so there.  That seems OK, but the stock AMC13Tool
one gets with ". ~daqowner/dist/etc/env.sh; AMC13Tool.exe" segfaults immediately :(




---+++ 2012-09-14, eric and charlie

Attempting to reproduce the result below and look at uHTR spy buffer
using tools [[http://ohm.bu.edu/~hazen/CMS/AMC13DebugData/AMC13Tool_3.taz][here]].
Perl script check_xxxx.pl loops generating one software L1A and checking using
dump_DTC.exe for EvN errors.

Found one!  AMC13 Data is [[http://ohm.bu.edu/~hazen/CMS/AMC13DebugData/test_2012-09-14_1.dat][here]].
uHTR DAQ spy output:

<pre>
> spy
  0000 2 00ff 
  0001 3 ffff Event number 16777215 (0xffffff)
  0002 3 8000 
  0003 3 03ee Orbit number 0, submodule number 1006 (0x3ee)
  0004 3 6000 Format 6, BCN 0 (0x0)
  0005 3 0017 Presamples 2, TP words 0 
  0006 3 4511 Unsuppressed 0, compact mode 1, firmware rev 0x511
  0007 3 0028 Flavor 0, Pipeline length 40 
  0008 3 2000 NS 4 WC 0
  0009 3 ffff 
  000a 3 0000 
  000b 1 ff00 
</pre>

This is not helpful as the EvN is for some reason all 1's.




---+++ 2012-09-13, eric and charlie

Testing V0.5.11 uCTR firmware with AMC13 V=0x17 S=0xb firmware

At 1kHz fixed trigger rate for 1s, take some data. ([[http://ohm.bu.edu/~hazen/CMS/AMC13DebugData/test_1khz_1sec.dat][here]]: warning!  binary file).

See that uHTR stay in sync with AMC13 but there are some strangely-corrupted events.

<pre>
Starting to read file...
First EvN is 1 (0x000001)
AMC13 EvN = 0x00000012  uHTR(10) EvN = 0x00451112 !!
AMC13 EvN = 0x0000004e  uHTR(4) EvN = 0x0045114e !!
AMC13 EvN = 0x00000218  uHTR(10) EvN = 0x0045111a !!
After reading 940 events, Last EvN is 940 (0x0003ac)
</pre>

Note the 4511's.  Here is a dump of !EvN 12

<pre>
AMC13 EvN = 0x00000012  uHTR(10) EvN = 0x00451112 !!
FED:   0 EvN: 000012  BcN: 1d5  OrN: 0008a747  TTS: 0/0 EvTyp: 1  CalTyp: 0 Size: 26
UHTR  4 [  12] EvN 000012 BcN 1d5 OrN 17
  0: 0412
  1: 0000
  2: 8000
  3: bbee
  4: 61d5
  5: 0017
  6: 4511
  7: 0028
  8: 2000
  9: ffff
 10: 0000
 11: 1208
UHTR 10 [  12] EvN 451112 BcN 1d7 OrN 04
  0: 0012
  1: 4511
  2: bbee
  3: 2000
  4: 61d7
  5: 0000
  6: 4539
  7: 2000
  8: ffff
  9: 0000
 10: 1208
 11: 0000
</pre>

Note that in the 2nd uHTR payload the high byte of the 1st word is 00 (should be 0a) plus the 2nd word is 4511 (should be 0000).  The 8000 word is missing, and the rest of the words
are shifted up by one.  The word count in the AMC13 header (see below) is 0b instead of 0c,
with a zero fill word added (correctly) by the AMC13.

Below is a raw dump of the data from the AMC13 excerpted.  (deadbeef and following word
count added by software).  Note the 4511 ffff

<pre>
000770 deadbeef 0000001a 1d500008 51000012
000780 008a7470 00000000 00000010 00170410
000790 00000000 00000000 0000c00c 00000000
0007a0 00000000 0000c00b 00000412 bbee8000
0007b0 001761d5 00284511 ffff2000 12080000
0007c0 45110012 2000bbee 000061d7 20004539
0007d0 0000ffff 00001208 ad8c0000 a000000d
0007e0 deadbeef 0000001a 1d500008 51000013
0007f0 008a7530 00000000 00000010 00170410
000800 00000000 00000000 0000c00c 00000000
000810 00000000 0000c00c 00000413 1bee8000
000820 001761d5 00284511 ffff2000 13080000
000830 00000a13 1bee8000 001761d5 00284511
000840 ffff2000 13080000 766b0000 a000000d
</pre>


---+++ 2012-08-31, hazen

Working on AMC13 "pre-ship" certification test.  Firmware up through virtex=0x10 have
LSC/LDC implemented and can send DAQ data in the old "Wu" format.  ]
Enable by turning on "SLINK Enable" (bit 1 in reg 1).  There are secret
counters which monitor the LDC:

<pre>
0x10 LDC_accept_cntr
0x11 LDC_abort_cntr
0x12 LDC_ACK_cntr
0x13 LDC_event_cntr
0x14 LDC_word_cntr
0x15 LDC_CRC_bad_cntr
0x16 LDC_SEQ_bad_cntr
0x17 LDC_wc_bad_cntr
0x18 LDC_frame_bad_cntr
0x19 LDC_buf_ovf_cntr
0x1a LDC_CMSCRC_err
</pre>



---+++ 2012-08-06, hazen

Download Jeremy's HEAD version from 8/2/12.  Compile 3 test BIT/MCS files:
   * Default (jumper/flash set IP address)
   * Fixed I/P address 192.168.1.34
   * Fixed I/P address 192.168.115.254

Flash the 1.34 version.  Responds to ping and mCTR2tool ok.
Now try the fixed 115.254 version.  Argh, the "reload" command once again doesn't work.  Cycle crate power.
It works... can talk to board at above IP.  

Now try flashing the "default" firmware.  "reload" works.
Can still access at 115.254.  Verify that SPI flash IP address is 1.32.  Remove jumper J1204 and re-power.
Still at 115.254 (sigh!).  Maybe messed up compiling.  _Confusion:_  Slot 5 board had no J1204, but _was_ installed
in board in slot 11.  Unplug slot 11 board altogether.  Still get a ping response from 115.254.

Re-install J1204 jumper on slot 4 and re-power.  Still get response from 115.254.  

Compile new version with original code but jumper-controlled backup address changed from 115.254 to 115.240.
Program this one to flash.  (J1204 is installed).  Do "reload".  Responds at 115.240 as expected.
Remove J1204 and re-power.  Still at 115.240.  Sigh.

Flash same firmware into other board.  Same results.

Try setting IP address to 192.168.115.40 (maybe 115 is somehow special).  No change.

Per Jeremy's request, program the 0.4.03 version from the [[http://cmsdoc.cern.ch/cms/HCAL/document/upgrade/uHTR/firmware/][web page]] into slot 11 board.  Once again "reload" doesn't work.  Power cycle.  Can't access the board at all.







---+++ 2012-08-02, hazen

Re-flash '2012-07-16a' version into both modules.  Fix a few bugs in AMC13DaqTest.exe so it can handle nested scripts correctly.  Run a few tests with script *AMC13DaqTest/test.amc* and see same event size in both mCTR.  More tomorrow.

---+++ 2012-08-01, hazen

Porting to ISE 14.  Removed cores defined in *ipcore_dir* and substitute ones from [[http://ohm.bu.edu/~hazen/CMS/SLHC/uHTR/Wu_Cores_30July.zip][Wu_Cores_30July.zip]] e-mailed by Wu.  Import into ISE 14.1 and re-compile.  Compiles OK and superficially works.  However, seeing some discrepancies in event length between old and new firmwares.

---+++ 2012-07-16, hazen

Merged changes are here:  [[http://ohm.bu.edu/~hazen/CMS/SLHC/uHTR/ctr2_merge_Wu.zip][ctr2_merge_Wu.zip]].
Now add them to project and re-compile.  Program into two mCTR2 in slots 5, 11 at IP addresses 192.168.1.32 and
192.168.1.40.

---+++ 2012-07-13, hazen

Wu has made some minor changes to the code to fix the link reset problem.
His changes are here:  [[http://ohm.bu.edu/~hazen/CMS/SLHC/uHTR/ctr2_Wu_Fix.zip][ctr2_Wu_Fix.zip]] but
must be merged with my firmware from here:  [[http://ohm.bu.edu/~hazen/CMS/SLHC/uHTR/ctr2_trunk_with_DAQ_2012-07-12a_esh.zip][ctr2_trunk_with_DAQ_2012-07-12a_esh.zip]].

I will start on this next week.


---+++ 2012-07-12, hazen

_Temporary solution to IP addressing:_  Assign a totally fixed address.  In ctr2_uhtr1600.v just set *ip_addr* to a fixed value.
Build two firmwares with addresses 192.168.1.32 and 192.168.1.40.  The board now in slot 5 is 32 and slot 11 is 40.

DAQ links do not work with this firmware:  [[http://ohm.bu.edu/~hazen/CMS/SLHC/uHTR/ctr2_trunk_with_DAQ_2012-07-12a_esh.zip][ctr2_trunk_with_DAQ_2012-07-12a_esh.zip]]

Will ask Wu for help.

---+++ 2012-07-11, hazen

Add two lines below to UCF and recompile per Wu's suggestion:
<pre>
  NET "*/DAQ_Link_wu/UsrClk" TNM_NET = "DAQ_UsrClk";
  TIMESPEC "TS_DAQ_UsrClk" = PERIOD "DAQ_UsrClk" 8ns HIGH 50%;
</pre>

*MiniCTR2 Programming:*

(instructions below from MN)

<pre>
  1) Program the 4.02 firmware bitfile from JTAG.
  2) mCTR2tool.exe 192.168.115.254 -t uhtr
  3) select your device (1).  Then FLASH -> PROGRAM (you'll need an MCS file)
      If Wu's firmware is branched from ours after 3.01, then you can do this with Wu's firmware.
  To change the IP address, use the SPICFG menu of mCTR2tool. 
</pre>

Here is what I did:

   * Generate MCS file with "generic parallel flash" and zero offset
   * mCTR2tool.exe 192.168.1.32 -t uhtr
   * "FLASH" then "PROG"

Doesn't work.  It's a 128M SPI flash.  That works better!

*IP Addressing* is a problem.  NAT-MCH doesn't seem to route packets to any addresses outside 192.168.1.xxx, even though the settings are now correct:

<pre>
[cms2] /home/hazen/work/uHTR_Firmware > telnet 192.168.1.11
Trying 192.168.1.11...
Connected to 192.168.1.11.
Escape character is '^]'.

Welcome to NAT-MCH

nat> ifconfig
network interface nat0:
  IP address:        192.168.1.11
  broadcast address: 192.168.255.255
  netmask:           255.255.0.0
nat>
</pre>
---+++ 2012-07-10, hazen

Attempting to integrate Wu's DAQ link into uHTR 4.02 release under ISE 13.3 on !VirtualBox ampere.bu.edu on Eric's desktop machine.

   * Rename Wu's *MiniCTR.vhd* to *DAQ_Link_wu.vhd* and put in =.../ctr2/ctr2_uhtr1600/DAQ_Path/= in project
      * Edit to remove chipscope stuff
   * Edit *DAQ_Link.vhd* to instantiate *DAQ_Link_wu.vhd*
   * Copy and add other sources:
      * Add *CRC16D16.vhd*
      * Add *Hamming.vhd*
      * copy =ipcore_dir= tree
      * Add *dataFIFO.ngc*, *DataBuf.ngc*, *TDP16_16.ngc*, *SDP16_16.ngc*

---+++ 2012-07-09, hazen

Basic DAQ event readout now seems to work.  Have added several useful commands
to my new tool *AMC13DaqTest* which is currently only in =~hazen/src/11_4_1=.

*HOWTO record test data*

Log on to CMS1 as user *daq* and start *DCCdiagnose.exe* to control TTC system.
Log on to CMS2 and run *AMC13DaqTest.exe*.  For now:
<verbatim>
  $ source ~hazen/environ.sh
  $ /src/11_5_1/hcal/hcalUpgrade/amc13/bin/linux/x86_64_slc5/AMC13DaqTest.exe
</verbatim>

| *cms1 (DCCdiagnose.exe)* | *cms2 (AMC13DaqTest.exe)* | *Notes* |
| | =en 5,11= | Enable AMC inputs (will change to 0,10 at some point).  Also resets AMC13 |
| =ttc/trig 4= | | Disable TTC triggers (set to VME control only) |
| =ttc/cmd 2= | | Issue TTC Event Count Reset command |
| =ttc/l1a 10= | | Generate 10 triggers |
| | =st= | Display AMC13 status |
|^| =Ctrl 0: 03000001= |^|
|^| =LSC Link Down= |^|
|^| =Ctrl 1: 000e0001= |^|
|^| =run mode= |^|
|^| =AMC Link status: 04100410= |^|
|^| =Mon buffer page: 00000000  Evts: 0000000a  words: 00000712= |^|
| | =df test.dat= | Dump events to file |

You can dump the file in hex as follows:
<verbatim>
   $ od -Ax -t x8 test.dat | less
   000000 00000712deadbeef 51000001c8c00008
   000010 000000059af5ddb0 000e041000000010
   000020 0000000000000000 000000000000c701
   000030 0000c70100000000 0800800000000401
   000040 0007000600058c8c 000b000a00090008
   000050 000f000e000d000c 0013001200110010
   000060 0017001600150014 001b001a00190018
   000070 001f001e001d001c 0023002200210020
     ....
   011af0 06f306f206f106f0 06f706f606f506f4
   011b00 06fb06fa06f906f8 705f06fe06fd06fc
   011b10 0000000000000a00 a00003891aca0000
</verbatim>




---+++ 2012-07-08, hazen

New firmware version 0xe.  Still see problem#2 below.  Investigating.

---+++ 2012-07-07, hazen

Trying to reproduce a DAQ firmware problem.

*Test #1 - failure to reset*

(set Xilinx board to deliver fast triggers at 20kHz)

| *cms1 (DCCdiagnose.exe)* | *cms2 (AMC13Tool.exe)* | *Notes* |
| =ttc/trig 1= | | Enable triggers |
| =ttc/trig 4= | | Disable triggers |
| | =wv 3 410= | Enable AMC inputs |
| | =wv 1 1= | Set run mode |
| | =wv 0 1= | Reset all |
| | =rv d= | Read word count |
| | =0xd 0x712= | FAIL: Should be zero! |
| | =wv 0 1= | Reset all |
| | =rv d= | Read word count |
| | =0xd 0= | Always zero 2nd time |

This fails intermittently.

*Test 2 with AMC13DaqTest.exe*

| *cms1 (DCCdiagnose.exe)* | *cms2 (AMC13DaqTest.exe)* | *Notes* |
| | =en 5,11= | Enable AMC inputs 5, 11 and reset AMC13 |
| =ttc/cmd 1= | | Reset EvN to 1 |
| =ttc/l1a= | | Make one trigger |
| | =rd= | Read and display event |
| | =ne= | advance to next event |
| =ttc/l1a= | | Make trigger |
| | =rv 0x4000 10= | See corrupted data |

This fails consistently:

It is probably a software problem, but it seems that I am competing for use of the
TTC system so stop for now.

---+++ 2012-07-05, hazen

Debugged AMC13 event readout code, added file dump feature to AMC13DaqTest.cc.  Discovered a firmware issue which causes data to appear incorrect after the first event, reported to Wu.

E-mailed Jeremy to ask about word order question.

---+++ 2012-07-01, hazen

Install new release 11_5_0 in *daqowner*.  Do not set as default yet.
Oops, 11_5_0 is buggy.  Update immediately to 11_5_1 and make it the default.

---+++ 2012-06-29, hazen

Checked in to CVS several updates of work done with Charlie.  

*HyperDAQ*

<ul>
*DTCManager.cc/hh* were updated to include Charlie's new HyperDAQ.  This required substantial changes to the address tables.  These changes were done to the existing files *AMC13_AddressTable_S6/V6.txt*.
</ul>

*Run Control*

<ul>
*AMC13.cc/hh* were updated to add *startRun()*, *endRun()*, *AMCInputEnable()*, *nextEventSize()*, *readNextEvent()*.
</ul>

---+++ 2012-06-27, rohlf

Fix *AMC13Tool* to support hex version names in firmware files.  Fork address tables with names *AMC13_AddressTable_S7/V8.txt*.
_FIXME:  This address table is now incompatible with the one used by the rest of the software!_

---+++ 2012-06-12, hazen

First release firmware and instructions for DAQ in AMC13:

<verbatim>
to set up L1A:
set L1a to about 20KHz
start dccdiagnose.exe
ttc/trig 4(turn off L1A)

run amc13tool
wv 3 410 (enable amc5 and amc11)
wv 1 1 (set run bit)
wv 0 1 (reset all)

ttc/cmd 0x28(reset orbit number)
ttc/trig 1 (enable L1A)

this will take 0x800 events in the memory and throw away all when the buffer is full.

In general, the initialization  and read out remains basically the same as with DCC2.
</verbatim>

---+++2012-05-24, rohlf
Sucessfully updated Spartan firmware from v3 to v6 at point 5. This was accomplished remotely in Bat. 40 at CERN with AMC13Tool by first writting Spartan v6 to flash at 0x000000 (its old location) as if programming the Header, power cycling the AMC13 module with the NAT tool, reprogramming the flash Header (0x000000), Golden (0x100000), Spartan (0x200000), and Virtex (0x400000), and then issuing the software command to reconfigure from flash.

---+++2012-05-24, rohlf
Update firmware in cDAQ lab at CERN using python software. Older software (now named amc13_python_backup-23-may2012) was used to program Spartan firmware v6 into 0x0, power cycle crate, program  Header (0x000000), Golden (0x100000), Spartan (0x200000), and Virtex (0x400000) where in the process a bug was discovered in programming the header due to incorrect erase of a single page, power cycling again, and verifying the configuration. 


---+++2012-04-27, hazen

Install HCAL xDAQ 11.4.0 (as daqowner) per instructions:

<pre>
To install on a teststand (as daqowner) :
      wget http://cmshcalweb01.cern.ch/hcalsw/release/installDAQ_11_4_0.perl
      perl installDAQ_11_4_0.perl --mode=teststand
      ~daqowner/common/bin/pickRelease.sh (choose 11.4.0)

You can make a code-development area on a teststand or USC using
      perl installDAQ_11_4_0.perl --mode=[teststand|usc]
--ownsource=${HOME}/src/11_4_0 --packages=hcalUpgrade --cvsuser=[your afs id]
You can list multiple packages, separated by commas.
</pre>

---+++2012-01-10, hazen

Trying to program a new AMC13 MMC.  Plug in to crate, connect JTAG ICE 3 cable
to JTAG connector.  Fails to program.  Try to force power on with "pwr_on 9"
(it's in AMC slot 4) but doesn't help.

Note:
<pre>
  pwr_on [fru #]
  pwr_off [fru #]

  where [fru #] is the fru number starting with 5 to16. That means if you
  want to switch on e.g. AMC2 use the command "pwr_on 6".
</pre>

Remembering wisdom of Tom Gorski:

<ul>
Maybe grasping at straws here, but if you look at the reset circuit for the AVR on the MMC schematic page, you see that it is important for the IPMI_ENABLE# line to be driven low, in order to release reset.  You didn't say what your power situation was to the card.  If you had it in a rig with an MCH trying to talk to the card, then the IPMI_ENABLE# line would indeed be zero, and the FET would not be pulling reset low, and the problem is probably somewhere else.  On the other hand, if you have the card in a rig with a dumb power supply, then AVR reset will be pulled low *unless* a shunt is installed at JMP4.  Since reset goes to the JTAG connector you might be able to check this with a voltmeter. 
</ul>

This should be taken care of by the uTCA backplane, no?  Meanwhile, trying to program the thing in Wu's test fixture.  Doesn't work.  Checking to be sure jumpers are installed.  *AHA* ... the required ECO (soldered wire) on the T3 board was missing.  Now all is OK.  One can indeed program the MMC on a new board in a MicroTCA crate.

Another observation:  an AMC won't power up fully without the front panel hardware installed, as the handle switch must be depressed for the negotiation with the MMC to complete.

---+++2011-12-06, heister

cms2: SLC5 updated, installation fine tuned, PyChips and microHAL installed for the "daq" user, all tested and works


---+++2011-12-06, hazen

Install 2nd NIC on cmssun2 (old Dell computer, Ubuntu 10.04 OS).  Cable to AMC13 in uTCA crate.
Install IPBus test firmware from Wu.  Install PyChips.  Works!  (I think).

Added 
[[http://bucms.bu.edu/twiki/bin/view/BUCMSPublic/AMC13FlashProgramming][AMC13FlashProgramming]]
page.

---+++2011-12-02, hazen

Started this log.  One dead NAT-MCH at Boston.  2nd NAT-MCH shipped from MN by Jeremy.

Reset I/P address to 192.168.1.11 and connect to CMS1.  One can now do =cms1> telnet 192.168.1.11=.  But, this MCH has firmware v2.0 which doesn't work with AMC13 (symptom is both red/green LEDs blink forever on AMC13 with MMC firmware V1.2).

Updating MCH firmware to V2.10 received from NAT on 9/20/11.  Briefly, the procedure is:

<pre>
  unzip the e-mail attachement somewhere
  copy the "bin" file to /tftpboot/mch on cms1.bu.edu
  connect to the MCH using the USB console and type "update_firmware" and follow the prompts
  type "reboot" to load the new firmware
</pre>

It works!  Now the AMC13 seems to be up and running with the MCH.

-- Main.EricHazen - 02 Dec 2011
Topic revision: r61 - 19 Jun 2013 - DavidZou
~~Edit~~
~~Attach~~