Difference: AMC13DebugLog (163 vs. 164)

Revision 16402 Sep 2022 - ChristopherCosby

Line: 1 to 1
 
META TOPICPARENT name="CmsSlhc"
Please log AMC13 test activity below, blog style (new entries at top)
Added:
>
>

2022-09-02, Chris Cosby

Tests done following TTTTtestInstructions

Test of "old" firmware (0x2264, 0x2e) running for several minutes outputting only TTS test pattern shows no anomolous registers counting

edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 10f: 0x00000000000000FF
Done!

With the same firmware, we switched to running with data from the fake AMC devices in slots 1-4. TTTT shows expected counters climbing (1=Overflow_warning, 8=Ready), and a slowly counting entry on an additional register (9=Private_Request_1)

edf@raspberrypi:~ $ python3 ttttControl.py resetCount
TCDS counters reset
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000006
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000011
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000017
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x000000000000003C
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000042
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000050
Done!

These were read out over the course of a couple minutes, about 10-30 seconds apart.

Repeating these tests with current firmware (0x2266, 0x34) shows the same results when sending the test pattern:

edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 10f: 0x00000000000000FF
Done!

and the same counters climbing when using real AMC devices for data

edf@raspberrypi:~ $ python3 ttttControl.py resetCount
TCDS counters reset
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000001
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000004
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000005
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x000000000000000D
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000023
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000025
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x000000000000002F
Done!

 

2016-11-01, Gastler

Added:
>
>
 The MCH issues seem to be the netmask on the MCH.

Packets sent to them from outside the 192.168.1.* network are received, but can't be routed back since the netmask is 24.

Line: 24 to 53
  Edit /etc/sysconfig/network-scripts/ifcfg-eth1 to change IP temporarily to 192.168.1.5.
Changed:
<
<
  # /sbin/ifdown eth1

>
>
  # /sbin/ifdown eth1

  # /sbin/ifup eth1
Line: 34 to 61
 or something like that. Probably Dan's DHCP experiments frown

Now Johnni says:

Changed:
<
<
ok so Ive tried various methods now to configure and send BGO commands from AMC13

>
>
ok so Ive tried various methods now to configure and send BGO commands from AMC13

 but I fail completely.

Im using version: 0x2255 and 0x02e.

Have you tested these versions in the lab recently to make sure you are still able to configure BGO commands such as Resynch (0x4) and see them in the TTC history?

Changed:
<
<
.
>
>
 
Changed:
<
<
Reprogram S/N 161 with 0x225b since it's the latest. Create a little script for Jonni:
>
>
.
 
Changed:
<
<
#

>
>
Reprogram S/N 161 with 0x225b since it's the latest. Create a little script for Jonni:
#

 # demo BGO # # enable AMC13 (needed to start TTC output)
Line: 102 to 129
 Used 258 to generate fake events for 86 and the FEROL successfully built the events. Dumps below.

From the FEROL:

Changed:
<
<
File 1:run000039_ls0001_index000001.raw

>
>
File 1:run000039_ls0001_index000001.raw

 EvN 000191 (000401) BcN 5ea ID 0064 Evt_ty=1 [1 blocks, 0x9 words] EvN 000192 (000402) BcN 2b6 ID 0064 Evt_ty=1 [1 blocks, 0x9 words] EvN 000193 (000403) BcN 313 ID 0064 Evt_ty=1 [1 blocks, 0x9 words]
Line: 113 to 140
 

From the AMC13:

Changed:
<
<
EvN 000001 (000001) BcN 19c ID 0064 Evt_ty=1   [1 blocks, 0x9 words] 

>
>
EvN 000001 (000001) BcN 19c ID 0064 Evt_ty=1   [1 blocks, 0x9 words] 

 EvN 00c351 (050001) BcN a5f ID 0064 Evt_ty=1 [1 blocks, 0x9 words] EvN 0186a1 (100001) BcN 5e2 ID 0064 Evt_ty=1 [1 blocks, 0x9 words] EvN 0249f1 (150001) BcN be8 ID 0064 Evt_ty=1 [1 blocks, 0x9 words]
Line: 121 to 148
 EvN 030d41 (200001) BcN 55c ID 0064 Evt_ty=1 [1 blocks, 0x9 words] EvN 03d091 (250001) BcN 5da ID 0064 Evt_ty=1 [1 blocks, 0x9 words]
Added:
>
>
 Status of AMC13 after disabling triggers:
Changed:
<
<
  Slink_Express|        SFP0|

>
>
  Slink_Express|        SFP0|

  --|------------| BACKPRESSURE_TIME| 0x14D8BA436| BLOCKS| 0x 55BC8|
Line: 159 to 187
 

2016-04-14, djarcaro

Deleted:
<
<
Creating a branch to test out using the unpacker class in AMC13.cc. I will start with AMC13::readEvent( size_t& nwords, int& rc) and have FedBlock do the parsing of a page from the monitor buffer.
 
Added:
>
>
Creating a branch to test out using the unpacker class in AMC13.cc. I will start with AMC13::readEvent( size_t& nwords, int& rc) and have FedBlock do the parsing of a page from the monitor buffer.
 

2016-03-29, hazen

Added:
>
>
 Fixing issues with the 10G FEROL software on CMS3, should help with cms2. The packages you get from the repos don't work and you have to remove/update to the following rpms: [http://ohm.bu.edu/~dgastler/CMS/daq-ferol-1.9.1-1.cmsos12.slc6.gcc4_4_7.x86_64.rpm daq-ferol-1.9.1-1] and [http://ohm.bu.edu/~dgastler/CMS/daq-ferol-devel-1.9.1-1.cmsos12.slc6.gcc4_4_7.x86_64.rpm daq-ferol-devel-1.9.1-1]

2016-03-02, hazen

Checking on MultiFED readout software. Tried first with test version 0x24a in S/N 161 and it behaved badly. Reprogramming now to HCAL 0x4043. Test seq:

Changed:
<
<
  daq 2

>
>
  daq 2

  wv CONF.EVB.ENABLE_DAQLSC 0 # turn off actual fiber output en 1,7 f t lt 5 100
Line: 183 to 210
 Diving into the code.

2016-02-18, dgastler

Added:
>
>
 Update on writing to disk. It appears that data writing to disk is working better now with ~15kHz of 1952byte events going to disk (30MBps).

Tried 8x larger events and 8x slower rate and xdaq died:

Changed:
<
<
evb::BU_0

>
>
evb::BU_0

 InfoSpaces: ApplicationMonitoring run 102Version 3.7.4 FailedPage last updated: Thu Feb 18 17:16:26 2016 UTC
Line: 206 to 232
 There are now no register on the FEROL end that this can be cross-referenced with, so this is entirely based on the fixed fake event size and the rate that the AMC13 reports data going at.

2016-02-12, dgastler

Added:
>
>
 It turns out that cms1 is not very fast and is the bottleneck for these speed tests.

Dominique instructed me on how to get the FEROL to drop the data when it lands and now the CPU use has dropped dramatically and the throughput went way up.

Here are the commands to throw away the data:

Changed:
<
<
>lspci -v

>
>
>lspci -v

  02:03.0 Memory controller: CMS DAQ group Device fea0 (rev 01) Flags: 66MHz, slow devsel
Changed:
<
<
Memory at dd210000 (32-bit, non-prefetchable) [size=64K]
>
>
Memory at dd210000 (32-bit, non-prefetchable) [size=64K]
  Memory at dd200000 (32-bit, non-prefetchable) [size=64K]
Changed:
<
<
>sudo busybox devmem 0xdd210000 32 0
>
>
>sudo busybox devmem 0xdd210000 32 0
 
Deleted:
<
<
 With 1952 Byte events, I was able to max out the AMC13's random event rate at 130kHz.

To try to max out the link, I increased the event size until I got backpressure. This happened at FAKE_DATA_SIZE of 0x40 (6560bytes) with a max rate of about 75kHz.

Line: 243 to 269
  With these settings the AMC13 reports an effective rate of about 30khz.
Deleted:
<
<
 

2016-02-10, dgastler

Added:
>
>
 Work on FEROL on CMS1

To get a fresh start on the xdaq software, I purged cms1 of xdaq using:

Changed:
<
<
% sudo yum erase daq-*

>
>
% sudo yum erase daq-*

 % sudo yum clean all

CMS1 is already pointing to the xdaq 12 repo, so after the purge, I did the following to re-install xdaq

Changed:
<
<
% sudo yum groupinstall extern_coretools

>
>
% sudo yum groupinstall extern_coretools

 % sudo yum groupinstall coretools % sudo yum groupinstall extern_powerpack % sudo yum groupinstall powerpack
Line: 273 to 297
 At this point the fedKit.py script will run and write to disk (most of the time) and for only certain sizes of events.

Here is a working AMC13 sequence:

Changed:
<
<
Using AMC13 software ver:41528
>rg

>
>
Using AMC13 software ver:41528
>rg

 General reset
Changed:
<
<
>rc
>
>
>rc
 Counter reset
Changed:
<
<
>en 1-12 t f
>
>
>en 1-12 t f
 parsed list "1-12" as mask 0xfff Enabling TTS as TTC for loop-back Enabling fake data AMC13 out of run mode AMC13 is back in run mode and ready
Changed:
<
<
>wv CONF.AMC.FAKE_DATA_SIZE 0x10
>
>
>wv CONF.AMC.FAKE_DATA_SIZE 0x10
 Write to register CONF.AMC.FAKE_DATA_SIZE
Changed:
<
<
>daq 1
>
>
>daq 1
 SFP0 enabled Best to do a DAQ reset (rd) after changing link settings
Changed:
<
<
>fed 0 100
>lt c
>wv CONF.AMC.FAKE_DATA_SIZE 0x20
>
>
>fed 0 100 >lt c >wv CONF.AMC.FAKE_DATA_SIZE 0x20
 Write to register CONF.AMC.FAKE_DATA_SIZE
Line: 300 to 323
 Increasing the event size worked until 0x100, where the system stopped recording data.

2016-01-21, dgastler

Added:
>
>
 Trying to find the size where the events break.

First, run the fedKit.py with no writing to disk, but set it to dump the next several events "e100".

Then run this script on the connected AMC13

Changed:
<
<
rg

>
>
rg

 rc en 1-12 f t localL1A o 1 1
Line: 348 to 372
 

This will generate increasing events until the "copy worker" dies with the error here:

Changed:
<
<
21 Jan 2016 17:48:11.625 [139692899636992] FATAL edu.bu.cms1.p: 33001.pt::frl::Application.instance(1) <> - Caught exception: pt::frl::exception::Exception 'Overflow of i2o: 32696' raised at processCopy(/usr/local/src/xdaq/baseline12/trunk/daq/pt/frl/src/common/CopyWork\
er.cc:301)
21 Jan 2016 17:48:11.626 [139693435836160] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0)  - Unhandled exception occured

>
>
21 Jan 2016 17:48:11.625 [139692899636992] FATAL edu.bu.cms1.p: 33001.pt::frl::Application.instance(1) <> - Caught exception: pt::frl::exception::Exception 'Overflow of i2o: 32696' raised at processCopy(/usr/local/src/xdaq/baseline12/trunk/daq/pt/frl/src/common/CopyWork er.cc:301)
21 Jan 2016 17:48:11.626 [139693435836160] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0) <toolbox/exception/Processor> - Unhandled exception occured

 Caught exception: pt::frl::exception::Exception 'failed to process copy for stream on index: 0 for copy worker id:0 - current frl event queue elements: 3 last processed input event dump: [[00000000] F8 01 F9 01 FA 01 FB 01 FC 01 FD 01 FE 01 FF 01 ........ ........ [00000010] 00 02 01 02 02 02 03 02 04 02 05 02 06 02 07 02 ........ ........ [00000020] 08 02 09 02 0A 02 0B 02 0C 02 0D 02 0E 02 0F 02 ........ ........
Line: 376 to 399
 The next event crashes the

2016-01-21, dgastler

Added:
>
>
 Trying to upgrade the firmware on the FEROL to p1_ferol_feb00027_1444987060.svf from feb 00020 Following https://twiki.cern.ch/twiki/bin/viewauth/CMS/UFEDKIT#Firmware_update

When using the fetKit.py write to disk option, it doesn't always start, and when it does, it won't write to disk and the "BU" xdaq icon has the error:

Changed:
<
<
Caught exception: exception::DiskWriting 'Failed to get value from EVM at http://cms1.bu.edu: 33001/urn:xdaq-application:lid=12/eventCountForLumiSection?ls=3: Couldn't resolve host name' raised at getValueFromEVM(/usr/local/src/xdaq/baseline12/trunk/daq/evb/src/common/bu/RUproxy.cc:539)

>
>
Caught exception: exception::DiskWriting 'Failed to get value from EVM at http://cms1.bu.edu: 33001/urn:xdaq-application:lid=12/eventCountForLumiSection?ls=3: Couldn't resolve host name' raised at getValueFromEVM(/usr/local/src/xdaq/baseline12/trunk/daq/evb/src/common/bu/RUproxy.cc:539)

 
Added:
>
>
 The log file has:
Changed:
<
<
21 Jan 2016 15:35:54.755 [139942756808448] FATAL edu.bu.cms1.p: 33001.evb::BU.instance(0) <> - Failed: Caught exception: exception::DiskWriting 'Failed to get value from EVM at http://cms1.bu.edu: 33001/urn:xdaq-application:lid=12/eventCountForLumiSection?ls=3: Couldn't resolve host name' raised at getValueFromEVM(/usr/local/src/xdaq/baseline12/trunk/daq/evb/src/common/bu/RUproxy.cc:539)
21 Jan 2016 15:35:54.755 [139942756808448] WARN  edu.bu.cms1.p: 33001.evb::BU.instance(0).RcmsStateNotifier <> - Unable to notify state change. RCMS state listener has not been found. Has findRcmsStateListener() been called at least once? State:Failed
21 Jan 2016 15:35:54.760 [139943433701120] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0)  - Unhandled exception occured

>
>
21 Jan 2016 15:35:54.755 [139942756808448] FATAL edu.bu.cms1.p: 33001.evb::BU.instance(0) <> - Failed: Caught exception: exception::DiskWriting 'Failed to get value from EVM at http://cms1.bu.edu: 33001/urn:xdaq-application:lid=12/eventCountForLumiSection?ls=3: Couldn't resolve host name' raised at getValueFromEVM(/usr/local/src/xdaq/baseline12/trunk/daq/evb/src/common/bu/RUproxy.cc:539)
21 Jan 2016 15:35:54.755 [139942756808448] WARN  edu.bu.cms1.p: 33001.evb::BU.instance(0).RcmsStateNotifier <> - Unable to notify state change. RCMS state listener has not been found. Has findRcmsStateListener() been called at least once? State:Failed
21 Jan 2016 15:35:54.760 [139943433701120] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0) <toolbox/exception/Processor> - Unhandled exception occured

 Caught exception: exception::DiskWriting 'Failed to get value from EVM at http://cms1.bu.edu: 33001/urn:xdaq-application:lid=12/eventCountForLumiSection?ls=3: Couldn't resolve host name' raised at getValueFromEVM(/usr/local/src/xdaq/baseline12/trunk/daq/evb/src/common/bu/RUproxy.cc:539)

2016-01-19, dgastler

  • With single events I've been ramping up the FAKE_DATA_SIZE register to see when xdaq breaks. With fake amcs 1-12 enabled,
Changed:
<
<
>lt 1

>
>
>lt 1

 detected number after 'lt' Sending 1 local triggers Trigger: 0 left
Changed:
<
<
>wv CONF.AMC.FAKE_DATA_SIZE 0x20
>
>
>wv CONF.AMC.FAKE_DATA_SIZE 0x20
 Write to register CONF.AMC.FAKE_DATA_SIZE
Changed:
<
<
>lt 1
>
>
>lt 1
 detected number after 'lt' Sending 1 local triggers Trigger: 0 left
Changed:
<
<
>wv CONF.AMC.FAKE_DATA_SIZE 0x40
>
>
>wv CONF.AMC.FAKE_DATA_SIZE 0x40
 Write to register CONF.AMC.FAKE_DATA_SIZE
Changed:
<
<
>lt 1
>
>
>lt 1
 detected number after 'lt' Sending 1 local triggers Trigger: 0 left
Changed:
<
<
>wv CONF.AMC.FAKE_DATA_SIZE 0x80
>
>
>wv CONF.AMC.FAKE_DATA_SIZE 0x80
 Write to register CONF.AMC.FAKE_DATA_SIZE
Changed:
<
<
>lt 1
>
>
>lt 1
 detected number after 'lt' Sending 1 local triggers Trigger: 0 left
Changed:
<
<
>wv CONF.AMC.FAKE_DATA_SIZE 0x100
>
>
>wv CONF.AMC.FAKE_DATA_SIZE 0x100
 Write to register CONF.AMC.FAKE_DATA_SIZE
Changed:
<
<
>lt 1
>
>
>lt 1
 detected number after 'lt' Sending 1 local triggers Trigger: 0 left
Changed:
<
<
>wv CONF.AMC.FAKE_DATA_SIZE 0x200
>
>
>wv CONF.AMC.FAKE_DATA_SIZE 0x200
 Write to register CONF.AMC.FAKE_DATA_SIZE
Changed:
<
<
>lt 1
>
>
>lt 1
 detected number after 'lt' Sending 1 local triggers Trigger: 0 left

This broke on the last one causing:

Changed:
<
<
19 Jan 2016 18:00:32.963 [140717694822144] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0)  - Unhandled exception occured
Caught exception: pt::frl::exception::Exception 'failed to process copy for stream on index: 0 for copy worker id:0 - current frl event queue elements: 2 last processed input event dump: [[00000000]   47 5A 00 00 80 00 01 FE   00 00 00 64 00 0\
0 00 06   GZ...... ...d....

>
>
19 Jan 2016 18:00:32.963 [140717694822144] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0) <toolbox/exception/Processor> - Unhandled exception occured
Caught exception: pt::frl::exception::Exception 'failed to process copy for stream on index: 0 for copy worker id:0 - current frl event queue elements: 2 last processed input event dump: [[00000000]   47 5A 00 00 80 00 01 FE   00 00 00 64 00 0 0 00 06   GZ...... ...d....

 [00000010] 08 64 40 1F 06 00 00 51 10 12 F9 01 40 83 C1 10 .d.....Q ........ [00000020] 00 00 01 00 03 02 00 0F 00 00 02 00 03 02 00 0F ........ ........ [00000030] 00 00 03 00 03 02 00 0F 00 00 04 00 03 02 00 0F ........ ........
Line: 453 to 476
 [000000f0] 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00 8.9..... ........ ]' raised at process(/usr/local/src/xdaq/baseline12/trunk/daq/pt/frl/src/common/CopyWorker.cc:583); originated by pt::frl::exception::Exception 'Overflow of i2o: 32696' raised at processCopy(/usr/local/src/xdaq/baseline12/trunk/daq/pt/frl/src/common/CopyWorker.cc:301)
Changed:
<
<
19 Jan 2016 18:08:32.848 [140716833482496] WARN edu.bu.cms1.p: 33001.pt::frl::Application.instance(1) <> - Caught exception: tcpla::exception::FailedToReceive 'Failed to receive, connection event reset in PublicServicePoint 10.0.0.5:34000 : UUID = '74997085-96d3-4e4b-af75-f3a72507ca06'' raised at processSocketEntries(/cmsnfshome0/nfshome0/dsimelev/baseline12/trunk/daq/tcpla/src/common/PublicServicePoint.cc:920); originated by tcpla::exception::ConnectResetByPeer 'Connection reset by peer in PublicServicePoint 10.0.0.5:34000 on file descriptor 9 socket error: Connection reset by peer' raised at receive(/cmsnfshome0/nfshome0/dsimelev/baseline12/trunk/daq/tcpla/src/common/PublicServicePoint.cc:560)
>
>
19 Jan 2016 18:08:32.848 [140716833482496] WARN edu.bu.cms1.p: 33001.pt::frl::Application.instance(1) <> - Caught exception: tcpla::exception::FailedToReceive 'Failed to receive, connection event reset in PublicServicePoint 10.0.0.5:34000 : U UID = '74997085-96d3-4e4b-af75-f3a72507ca06'' raised at processSocketEntries(/cmsnfshome0/nfshome0/dsimelev/baseline12/trunk/daq/tcpla/src/common/PublicServicePoint.cc:920); originated by tcpla::exception::ConnectResetByPeer 'Connection reset by peer in PublicServicePoint 10.0.0.5:34000 on file descriptor 9 socket error: Connection reset by peer' raised at receive(/cmsnfshome0/nfshome0/dsimelev/baseline12/ trunk/daq/tcpla/src/common/PublicServicePoint.cc:560)
 
Line: 460 to 481
 
Deleted:
<
<
 
  • Tried with 6 fake AMCs which worked at 10hz, upping to 100hz crashed xdaq "copy worker"

Copy worker failed with

Changed:
<
<
19 Jan 2016 16:15:37.684 [140287254984448] FATAL edu.bu.cms1.p: 33001.pt::frl::Application.instance(1) <> - Caught exception: pt::frl::exception::Exception 'Overflow of i2o: 32696' raised at processCopy(/usr/local/src/xdaq/baseline12/trunk/daq/pt/frl/src/common/CopyWork\
er.cc:301)
19 Jan 2016 16:15:37.685 [140287800329984] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0)  - Unhandled exception occured

>
>
19 Jan 2016 16:15:37.684 [140287254984448] FATAL edu.bu.cms1.p: 33001.pt::frl::Application.instance(1) <> - Caught exception: pt::frl::exception::Exception 'Overflow of i2o: 32696' raised at processCopy(/usr/local/src/xdaq/baseline12/trunk/daq/pt/frl/src/common/CopyWork er.cc:301)
19 Jan 2016 16:15:37.685 [140287800329984] ERROR edu.bu.cms1.p: 33001.executive::Application.lid(0) <toolbox/exception/Processor> - Unhandled exception occured

 Caught exception: pt::frl::exception::Exception 'failed to process copy for stream on index: 0 for copy worker id:0 - current frl event queue elements: 1 last processed input event dump: [[00000000] 47 5A 00 00 80 00 01 FE 00 00 00 64 00 00 00 01 GZ...... ...d.... [00000010] 08 64 50 56 01 00 00 51 00 ED 57 22 C0 81 61 10 .dPV...Q ..W...a. [00000020] 00 00 01 00 03 04 00 0F 00 00 02 00 03 04 00 0F ........ ........
Line: 499 to 517
 Here is the setup of that run:

On the AMC13 (after a reconfigureFPGAs):

Changed:
<
<
>rg

>
>
>rg

 General reset
Changed:
<
<
>rc
>
>
>rc
 Counter reset
Changed:
<
<
>en 1 f t
>
>
>en 1 f t
 parsed list "1" as mask 0x1 Enabling fake data Enabling TTS as TTC for loop-back AMC13 out of run mode AMC13 is back in run mode and ready
Changed:
<
<
>daq 1
>
>
>daq 1
 SFP0 enabled Best to do a DAQ reset (rd) after changing link settings
Changed:
<
<
>fed 0 100
>localL1A r 10 10
>
>
>fed 0 100 >localL1A r 10 10
 Configure LocalL1A enabled mode=2 burst=10 rate=10 rules=0 WARNING: AMC13 random trigger mode, setting burst to 1 L1A per burst

FedKit:

Changed:
<
<
[dan@cms1 FEROL]$ /opt/xdaq/bin/fedKit.py 

>
>
[dan@cms1 FEROL]$ /opt/xdaq/bin/fedKit.py 

 Welcome to the optical FEDkit ========================= Please select the data source to be used:
Line: 529 to 547
  2 - Generator core of the AMC13 (L6G_CORE_GENERATOR_SOURCE) 3 - Loopback at the FEROL (L6G_LOOPBACK_GENERATOR_SOURCE) 4 - SLINK data source (SLINK_SOURCE)
Changed:
<
<
=> [1]
>
>
=> [1]
 Please enter the FED id you want to read out [100]: Do you want to write the data to disk? [No]: Starting run...
Line: 540 to 558
 e# dump the next # Events with FED data only (default 1) q stop the run and Quit

Changed:
<
<
=>
>
>
=>
 

Back on the AMC13:

Changed:
<
<
>lt c

>
>
>lt c

 Enable continuous local triggers

Line: 557 to 575
 Event dump file: http://bucms.bu.edu/twiki/pub/Main/AMC13DebugLogdump_run000052_event00006104.txt

2015-12-11, dgastler

Added:
>
>
 Using an AMC13 + FEROL + 10Gb nic on cms1 I was able to get the save to disk mode to start by using the following startup procedure.

On the amc13:

Changed:
<
<
reconfigureFPGAs

>
>
reconfigureFPGAs

 
Added:
>
>
 wait...
Changed:
<
<
rg

>
>
rg

 rc en 1-12 f t daq 1
Line: 573 to 593
 fed 0 100 localL1A o 1 1
Added:
>
>
 FEDKit:
Changed:
<
<
fedKit.py 

>
>
fedKit.py 

 
Line: 586 to 607
  2 - Generator core of the AMC13 (L6G_CORE_GENERATOR_SOURCE) 3 - Loopback at the FEROL (L6G_LOOPBACK_GENERATOR_SOURCE) 4 - SLINK data source (SLINK_SOURCE)
Changed:
<
<
=> [1]
>
>
=> [1]
 Please enter the FED id you want to read out [100]: Do you want to write the data to disk? [Yes]: Please enter the directory where the data shall be written [/tmp]:
Line: 600 to 621
 

AMC13:

Deleted:
<
<
  lt 5
 
Added:
>
>
  lt 5
  This still doesn't write to disk, but it does get to the user menu for the fedKit.py script

2015-12-11, dgastler

Line: 624 to 645
 On CMS1 open two terminals so you can run the fedKit.py and AMC13Tool2.exe.

Setup the AMC13 for fake data taking:

Changed:
<
<
>rg

>
>
>rg

 General reset
Changed:
<
<
>rc
>
>
>rc
 Counter reset daq 1 SFP0 enabled Best to do a DAQ reset (rd) after changing link settings
Changed:
<
<
>rd
>
>
>rd
 DAQ reset
Changed:
<
<
>en 1-12 t f
>
>
>en 1-12 t f
 parsed list "1-12" as mask 0xfff Enabling TTS as TTC for loop-back Enabling fake data AMC13 out of run mode AMC13 is back in run mode and ready
Changed:
<
<
>localL1A o 1 1
>
>
>localL1A o 1 1
 Configure LocalL1A enabled mode=0 burst=1 rate=1 rules=0

Setup the FEROL in the daq account as follows:

Changed:
<
<
[daq@cms1 FEROL]$ fedKit.py 

>
>
[daq@cms1 FEROL]$ fedKit.py 

 Welcome to the optical FEDkit ========================= Please select the data source to be used:
Line: 654 to 675
  2 - Generator core of the AMC13 (L6G_CORE_GENERATOR_SOURCE) 3 - Loopback at the FEROL (L6G_LOOPBACK_GENERATOR_SOURCE) 4 - SLINK data source (SLINK_SOURCE)
Changed:
<
<
=> [1]
>
>
=> [1]
 Please enter the FED id you want to read out [1234]: Do you want to write the data to disk? [No]: Starting run...
Line: 665 to 686
 e# dump the next # Events with FED data only (default 1) q stop the run and Quit

Changed:
<
<
=>
>
>
=>
 
Line: 697 to 717
  Finding apparent bugs in AMC13 monitor buffer. Here are some notes for someone to pick up the trail.
Changed:
<
<
First, read Monitor Buffer documentation.
>
>
First, read Monitor Buffer documentation.
 Then, review the data format documentation.

One can set the size of fake data by writing to CONF.AMC.FAKE_DATA_SIZE. By default this is set to 0x400 which results in unsegmented (single-block) events. If you set this larger than the somewhat arbitrary value of 0x13fb (about 40k bytes) then you get a segmented event. The table below illustrates this:

FAKE_DATA_SIZE Blocks Block 0 size Block 1 size Block 2 size
Changed:
<
<
<= 0x13fb 1 0x13fe - -
>
>
<= 0x13fb 1 0x13fe - -
 
0x13fc 2 0x1000 0x3ff -
0x23fb 2 0x1000 0x13fe -
0x23fc 3 0x1000 0x1000 0x3ff
Line: 708 to 728
 
0x23fb 2 0x1000 0x13fe -
0x23fc 3 0x1000 0x1000 0x3ff
0x3000 3 0x1000 0x1000 0x1003
Deleted:
<
<
 It's a bit confusing, but essentially you can generate events with different number of blocks by setting FAKE_DATA_SIZE. The bugs start when you have e.g. 2 free buffers and try to store an event which requires 3. Here is the command sequence to trigger this apparent bug:
Changed:
<
<
  > wv CONF.AMC.FAKE_DATA_SIZE 0x100       # small size for single blocks
  > lt 0x3fe                               # generate 1k - 2 triggers
  > st 2 Monitor_Buffer                    # two empty buffers (0x400 - 2)

>
>
  > wv CONF.AMC.FAKE_DATA_SIZE 0x100       # small size for single blocks
  > lt 0x3fe                               # generate 1k - 2 triggers
  > st 2 Monitor_Buffer                    # two empty buffers (0x400 - 2)

  Monitor_Buffer| COUNT| VALUE| --|------|------| AVAILABLE| | 1| EMPTY| | 0| UNREAD_EVT| 0x3FE| |
Changed:
<
<
>wv CONF.AMC.FAKE_DATA_SIZE 0x3000 >lt >st 2 Monitor_Buffer
>
>
>wv CONF.AMC.FAKE_DATA_SIZE 0x3000 >lt >st 2 Monitor_Buffer
  Monitor_Buffer| COUNT| VALUE| --|------|------| AVAILABLE| | 0| # if AVAILABLE=0 FULL should be 1 EMPTY| | 0| UNREAD_EVT| 0x3FE| |
Changed:
<
<
>re # read one event, freeing one buffer >st 2 Monitor_Buffer
>
>
>re # read one event, freeing one buffer >st 2 Monitor_Buffer
  Monitor_Buffer| COUNT| VALUE| --|------|------| AVAILABLE| | 0|
Line: 744 to 760
 New NIC installed as eth6 on CMS1. It should come up as 10.0.0.5. Running fedKit.py with option 3 (loopback at ferol) seemed to work, but I haven't gotten any data out using the f and e commands.
Deleted:
<
<
 

2015-09-24, hazen/gastler

FEROL connected in mini-crate to CMS4. Shows up in lspci as

Changed:
<
<
  06:04.0 Memory controller: Device ecd6:fea0 (rev 01)

>
>
  06:04.0 Memory controller: Device ecd6:fea0 (rev 01)

 
Added:
>
>
 But, cms4 has FNAL Scientific Linux and thus no xDAQ frown Moving the minicrate/card to cms1 even though the 10GbE NIC doesn't work there. (The 10GbE NIC is in l3ibm and it does work there, but this is also FNAL Linux).
Line: 770 to 785
 Now it completes with no password prompts!

Here's the install/build sequence:

Changed:
<
<
$ source /home/daqowner/dist/etc/env.sh
$ perl installDAQ_12_4_9.perl --mode=teststand \
 --ownsource=${HOME}/src/12_4_9 \
 --svnuser=ehazen \
 --packages=all

>
>
$ source /home/daqowner/dist/etc/env.sh
$ perl installDAQ_12_4_9.perl --mode=teststand   --ownsource=${HOME}/src/12_4_9   --svnuser=ehazen   --packages=all

 $ cd src/12_4_9/hcal $ #---- EDIT MAKEFILE to add hcalUTCA to SUBPACKAGES ---- $ make
Line: 797 to 807
 Also found that David's code hack in DTCManager to set the calibration trigger orbit gap has no error check whatsoever and will fail badly for most values of the orbit gap settings. For now edit DTCManager.cc to:
Changed:
<
<
    // Enable calibration events in orbit gap if config doc says so                                                                                                              

>
>
    // Enable calibration events in orbit gap if config doc says so                                                                                                              

  if (m_calibEnable){
Changed:
<
<
m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_ENABLE",1);
>
>
m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_ENABLE",1);
  try { // Set calibration orbit gap window // substract 3456 since only writing to editable part
Changed:
<
<
m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_WINDOW_LOWER_PROG", m_calibLower-3456); m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_WINDOW_UPPER_PROG", m_calibUpper-3456);
>
>
m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_WINDOW_LOWER_PROG", m_calibLower-3456); m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_WINDOW_UPPER_PROG", m_calibUpper-3456);
  } catch( std::exception& e) { LOG4CPLUS_ERROR(getApplicationLogger(), ::toolbox::toString("DTCManager::init() setting orbit gap to %d-%d", m_calibLower, m_calibUpper)); } }
Changed:
<
<
else m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_ENABLE",0);
>
>
else m_dtc->write(amc13::AMC13Simple::T1,"CONF.CAL_ENABLE",0);
 

2015-06-30, dzou

Line: 835 to 843
 But when you boot from the CD-ROM it can't find the utilities it needs!

Here is what I managed:

Changed:
<
<
Copy ISO to both CDROM and USB stick

>
>
Copy ISO to both CDROM and USB stick

 insert CDROM only and boot from it (F12 for boot menu) wait for it to time out, failing to find CDROM insert usbstick
Line: 862 to 866
  Tried running the /opt/xdaq/bin/fedKit.py script but it fails.
Deleted:
<
<
 

2015-03-09, hazen

Testing firmware 0x222, 0x27 with software rel 34315 on CMS4. Seeing uHAL timeouts while reading data using 'df' command. Example:

Changed:
<
<
  $ AMC13Tool2.exe -c 192.168.1.82

>
>
  $ AMC13Tool2.exe -c 192.168.1.82

  $ Address table path "/home/hazen/work/amc13/amc13/etc/amc13" set from AMC13_ADDRESS_TABLE_PATH use_ch false Created URI from IP address: T2: ipbusudp-2.0://192.168.1.82:50001 T1: ipbusudp-2.0://192.168.1.83:50001 Using AMC13 software ver:34315
Changed:
<
<
> en 1-12 f t > localL1A o 1 10 > lt c > lt d > df test.dat 9999
>
>
> en 1-12 f t > localL1A o 1 10 > lt c > lt d > df test.dat 9999
  ... Read 12340 words Wrote 12342 words to test.dat
Line: 948 to 949
 in last octet = 255/254.

MAC addresses set as follows

Changed:
<
<
Nmap scan report for rfc1918.address.not.used.bu.edu (192.168.2.56)

>
>
Nmap scan report for rfc1918.address.not.used.bu.edu (192.168.2.56)

 Host is up (0.000064s latency). MAC Address: 08:00:30:F3:01:9C (Network Research) Nmap scan report for rfc1918.address.not.used.bu.edu (192.168.2.57)
Line: 958 to 959
 

The documented scheme is:

Changed:
<
<
  bits 0-5     complement of serial number bits 0-5

>
>
  bits 0-5     complement of serial number bits 0-5

  bit 6 =0 for T2 board (lower IP) =1 for T1 board (upper IP)
Changed:
<
<
bit 7, 8 serial number bits 6, 7 (not complemented for S/N < 64 only)
>
>
bit 7, 8 serial number bits 6, 7 (not complemented for S/N < 64 only)
 

I'm confused.

Changed:
<
<
Update T1 FW per Wu's suggestion (to 0x21b) and now it looks better:
Nmap scan report for rfc1918.address.not.used.bu.edu (192.168.2.56)

>
>
Update T1 FW per Wu's suggestion (to 0x21b) and now it looks better:

Nmap scan report for rfc1918.address.not.used.bu.edu (192.168.2.56)

 Host is up (0.000087s latency). MAC Address: 08:00:30:F3:01:9C (Network Research) Nmap scan report for rfc1918.address.not.used.bu.edu (192.168.2.57)
Line: 1007 to 1005
  http://ohm.bu.edu/~hazen/CMS/AMC13/AMC13XG_T1_v0x800a_utilization.txt
Deleted:
<
<

 

2014-09-02, dzou

Suggestion for troubleshooting AMC13 with uHTR initialization:

Changed:
<
<
  1. Reload AMC13 firmware
  2. Disable uHTR DAQ Path
  3. Power cycle modules
>
>
  1. Reload AMC13 firmware
  2. Disable uHTR DAQ Path
  3. Power cycle modules
 -- OR --
Changed:
<
<
  1. Reload firmware for module using software (in principle this should have the effect as powercycle)
  2. Rerun initialization
>
>
  1. Reload firmware for module using software (in principle this should have the effect as powercycle)
  2. Rerun initialization
 

2014-08-21, Eric

To run csv_to_xml.pl script in ...amc13/dev_tools/cfg/addrTableTools, need to install perl module Tree::Simple. Do this with:

Deleted:
<
<
   $ sudo yum install perl-Tree-Simple
 
Added:
>
>
   $ sudo yum install perl-Tree-Simple
 

2014-08-19, Dan, Eric

Line: 1042 to 1034
 
Orbit delay for data alignment of links Who knows, enter a small integer
Set of slots to use, separated by commas 1-based list of slots
Pipeline length for pulling out the data from the UHTR Who knows, enter a small integer
Deleted:
<
<
 Sample connection file: sample_xdaq_connections.xml. Set for crate number 1.

Must edit standalone-daq.xml because of a bug somewhere... in the UHTR { ... } section find the line "if ( SLOT in..." and change to:

Changed:
<
<
  if ( SLOT == 2 ) {

>
>
  if ( SLOT == 2 ) {

 

If using local triggers also add to DTC{...} section:

Changed:
<
<
  localTtcSignal=true

>
>
  localTtcSignal=true

  internalPeriodicTriggerEnable=true

(once only) start control hub:

Changed:
<
<
  sudo /etc/init.d/controlhub start

>
>
  sudo /etc/init.d/controlhub start

 

Then: sh run-standaone.sh.

Line: 1103 to 1088
 
  • Address Tables and Mr. Wu Spec files?

Places to change code:

Changed:
<
<
  1. singleBit_OnOff is a method that checks bits and populates a vector of strings indicating with AMC ports have their relevant bit set (in 0-based enumation). All Status display items from AMC Link Status through Bc0 Status use this to enumerate. (Actions.cc, line 2625)
>
>
  1. singleBit_OnOff is a method that checks bits and populates a vector of strings indicating with AMC ports have their relevant bit set (in 0-based enumation). All Status display items from AMC Link Status through Bc0 Status use this to enumerate. (Actions.cc, line 2625)
 
    • Up front my guess at the fix:
Changed:
<
<
      1. (ss bit shift by i+1? and the if statement to i<=10) or
>
>
      1. (ss bit shift by i+1? and the if statement to i<=10) or
 
      1. (loop i starting at i=1 and make the appropriate shifts throughout loop)
Changed:
<
<
  1. ctr64_status_amc is the method use in AMC Counters. (Actions.cc, line 2657, ena_amcs[i] )
>
>
  1. ctr64_status_amc is the method use in AMC Counters. (Actions.cc, line 2657, ena_amcs[i] )
 
    • ena_amcs is populated by singleBit_OnOff, so if singleBit_OnOff is made to give a vector of 1-based strings, then it may not be necessary to change ctr64_status_amc at all.
Deleted:
<
<
 

2014-07-18, dzou

Multiple users have experienced problems with receiving/sending Bc0s from their AMC13. Unfortunately, we do not have the same hardware and we are experiencing difficulties providing support, as it is hard to determine if the issue is in fact due to the AMC13.

Line: 1138 to 1120
  Working on flash programming exceptions problem. Add a "readRepeat" command to new AMC13Tool which takes chip / address / count. Occasionally it fails:
Deleted:
<
<
 
>readRepeat 0 0x1080 100000
terminate called after throwing an instance of 'uhal::exception::UdpTimeout'
Changed:
<
<
what(): Timeout (1000 milliseconds) occurred for UDP receive from target with URI: ipbusudp-2.0://192.168.1.90:50001
>
>
what(): Timeout (1000 milliseconds) occurred for UDP receive from target with URI: ipbusudp-2.0://192.168.1.90:50001
  Take GbE switch out (connect yellow cable direct from CMS2 to Vadatech MCH). Now flash programming is reliable. Maybe the TTT was causing trouble? Disconnect it.
Line: 1168 to 1147
 10: MMC: 2.2 IP: 192.168.1.74 192.168.1.75 vv: 0x1000 sv: 0x0020 sn: 90 temp: 400 11: MMC: 2.2 IP: 192.168.1.106 192.168.1.107 vv: 0x0108 sv: 0x0021 sn: 74 temp: 706 12: MMC: 2.2 IP: 192.168.1.56 192.168.1.57 vv: 0x0109 sv: 0x0021 sn: 99 temp: 668
Changed:
<
<
13: MMC: 2.2 IP: 192.168.1.90 192.168.1.91 vv: 0x0209 sv: 0x0021 sn: 82 temp: 702
>
>
13: MMC: 2.2 IP: 192.168.1.90 192.168.1.91 vv: 0x0209 sv: 0x0021 sn: 82 temp: 702
 

2014-07-1, aguld

Line: 1223 to 1200
 
      • Python scripts (readIPs, applyConfig, etc) confirmed working
      • Used (192.168.1.2) as MCH host IP for python scripts.
    • Not able to ping 10/100 port, when connected to Gigabit Ethernet port (NOTE: This is likely because the broadcast of cmssun's eth1 is not set to communicate w/ address outside of 192.168.1 while cms2 is set to for all addresses between 192.168.1.-192.168.255.):
Changed:
<
<
ping 192.168.2.2

>
>
ping 192.168.2.2

 PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data. From 128.197.254.113 icmp_seq=1 Time to live exceeded From 128.197.254.113 icmp_seq=2 Time to live exceeded
Line: 1252 to 1229
 uHTR is able to receive clock. But the link does not report a lock, and there are various error counters incrementing (single, multi, BC0/BcN mismatch):

AMC13 status:

Changed:
<
<
*****AMC13 Status*****

>
>
*****AMC13 Status*****

 Status display detail level: 1 Control 0: 56000009 DAQLSC Link Down
Line: 1279 to 1256
  Busy time [004c]: 00000000 00000001 L1A ovfl warn time [0050]: 00000000 00000001 AMC Counters:
Changed:
<
<
<---Link 01----->
>
>
  Single Bit Error [0042]: 00000001 77701dd0 Multi Bit Error [0044]: 00000000 a6c5db68 BC0 Mismatch [0046]: 00000000 00a543fe BcN Mismatch [0048]: 00000000 00000280 Resend [004a]: 00000000 003bf6b2
Changed:
<
<

uHTR status and uHTR DTC status:

>
>
uHTR status and uHTR DTC status:

  ID[0] IP[192.168.115.8] Type: uHTR ID of uHTR (-1 for exiting the tool) :: [0] uHTR baseboard V1.0 Serial number 65535
Line: 1321 to 1295
  FLASH Flash programming and readback menu LUMI LUMI-DAQ work EXIT Exit this tool
Changed:
<
<
> dtc
>
>
> dtc
  STATUS Status of the DTC/TTC ERR_RESET Reset the error counters DELAY Set the delay of the TTC stream manually QUIT Back to top menu
Changed:
<
<
> status
>
>
> status
  ============================================ Front FPGA: Back FPGA: Event Num : 5052417 5052417
Line: 1345 to 1319
  TTC Stream Phase : Locked Locked

2014-05-28, dzou, aguld

Added:
>
>
 AMC13 boards with issues:
  • SN 78
    • Error when trying to configure Device 1 (T2) in Chipscope
    • When trying to reprogram MMC, Error occurs upon attempting to read Device:
Changed:
<
<
Unable to enter programming mode. The read device ID does not match the slected device or any other supported devices. 

>
>
Unable to enter programming mode. The read device ID does not match the slected device or any other supported devices. 

 Please verify device selection, interface settings, target power and connections to the target device

Severity: Error

Line: 1377 to 1351
 
      • Basic command do not seem to be working
      • T1 firmware reads 0x0 (instead of 0x108, which is what is programmed onto the board)
      • Event builder counters seem to be stuck at non-zero values (general and counter resets do not reset them)
Changed:
<
<
Pick an action (h for menu): st

>
>
Pick an action (h for menu): st

  ****AMC13 Status**** Status display detail level: 1
Line: 1406 to 1379
  Using EricReadTest v0.1 (in amc13simple). Enter commands:
Changed:
<
<
amc13> i 3 0x20000         initialize two inputs for fakes length 0x20000
amc13> t                   generate one trigger
amc13> r 0xd               read size

>
>
amc13> i 3 0x20000         initialize two inputs for fakes length 0x20000
amc13> t                   generate one trigger
amc13> r 0xd               read size

  0000000d: 0000400a size is 400a 32-bit words (0x2005 64-bit words)
Changed:
<
<
amc13> d 0x20000 0x20 dump header
>
>
amc13> d 0x20000 0x20 dump header
 

Here's the header dump. Seems OK, but AMC1 payload header wrong

Changed:
<
<
amc13>rd 0x20000 0x20

>
>
amc13>rd 0x20000 0x20

 000000: 510000011f400008 CDF Header 000001: 1020000000016dc0 block header, nAMC=2 000002: 2e02000300010000 AMC1 info size=0x20003 2=first block e=EPV
Line: 1425 to 1396
 

Here is the AMC1 payload

Changed:
<
<
000004: 010000011f420003    AMC1 header length=0x20003 (upper byte incorrect)

>
>
000004: 010000011f420003    AMC1 header length=0x20003 (upper byte incorrect)

 000005: 0007000616dc0000 OrN, ID ok, counter start with 0007 000006: 000b000a00090008 000007: 000f000e000d000c

Here is the AMC2 payload

Changed:
<
<
022002: 3ff73ff63ff53ff4

>
>
022002: 3ff73ff63ff53ff4

 022004: 3ffb3ffa3ff93ff8 022006: 3fff3ffe3ffd3ffc Trailer is missing(?) 022008: 020000011f420003 AMC2 header size=0x20003
Line: 1447 to 1414
 

Here is the end of the block

Changed:
<
<
amc13>rd 0x24004 0x20

>
>
amc13>rd 0x24004 0x20

 024004: 3ffb3ffa3ff93ff8 024006: 3fff3ffe3ffd3ffc end of payload 024008: cef9355d000011f4 This looks like the block trailer
Line: 1457 to 1422
 

Now on to the next block

Changed:
<
<
amc13>w 0xc 0
amc13>rd 0x20000 0x20

>
>
amc13>w 0xc 0
amc13>rd 0x20000 0x20

 020000: 1020000000016dc0 block header 020002: 3a00100000110000 AMC1 info size=1000 3=mid block a=EV (no P) 020004: 3e00100000120000 AMC2 info size=1000 3=mid block e=EPV
Line: 1470 to 1433
 

Second AMC

Changed:
<
<
amc13>rd 0x22000 0x20

>
>
amc13>rd 0x22000 0x20

 022000: 7ff77ff67ff57ff4 022002: 7ffb7ffa7ff97ff8 022004: 7fff7ffe7ffd7ffc
Line: 1481 to 1442
 

End of block

Changed:
<
<
amc13>rd 0x24000 0x20

>
>
amc13>rd 0x24000 0x20

 024000: 7ff77ff67ff57ff4 024002: 7ffb7ffa7ff97ff8 024004: 7fff7ffe7ffd7ffc
Line: 1494 to 1453
 

Block 3

Changed:
<
<

amc13>rd 0x20000 0x20

>
>
amc13>rd 0x20000 0x20

 020000: 1020000000056540 Block header 020002: 3e00100000210000 AMC1 info 020004: 3e00100000220000 AMC2 info
Line: 1521 to 1477
  Try size=0x1800 (1-1/2 blocks)
Changed:
<
<
amc13>i 3 0x1800 amc13>t amc13>r 0xd
>
>
amc13>i 3 0x1800 amc13>t amc13>r 0xd
 0000000d: 0000400a
Changed:
<
<
amc13>rd 0x20000 0x10
>
>
amc13>rd 0x20000 0x10
 020000: 510000011f400008 CDF header 020002: 102000000002ab50 Block header 020004: 2e00180300010000 AMC1 info
Line: 1546 to 1502
 024006: 3fff3ffe3ffd3ffc 024008: 77303f30000011f4 Block trailer 02400a: 77303f30000011f4
Changed:
<
<
>
>
</pre>
  Next block
Changed:
<
<
amc13>w 0xc 0
amc13>r 0xd

>
>
amc13>w 0xc 0
amc13>r 0xd

 0000000d: 00002016
Changed:
<
<
amc13>rd 0x20000 0x10
>
>
amc13>rd 0x20000 0x10
 020000: 102000000002ab50 Block header 020002: 1f00080300110000 AMC header size=803 1F=end EPVC 020004: 1f00080300120000 AMC header size=803 1F=end EPVC
Line: 1591 to 1545
 022016: a000301063220000 end
Deleted:
<
<
 

2014-05-19, hazen

HOWTO add new fields to the board database

Changed:
<
<
  1. Check out a test copy somewhere cgi scripts can be run (David can to this in his public_html on ohm)
>
>
  1. Check out a test copy somewhere cgi scripts can be run (David can to this in his public_html on ohm)
 
    1. svn co https://edf.bu.edu/svn/edf/AMC13/boards
Changed:
<
<
  1. Point browser at the copy you have checked out to be sure it works, e.g.:
>
>
  1. Point browser at the copy you have checked out to be sure it works, e.g.:
 
    1. http://edf.bu.edu/~hazen/DBTest/boards/view
Changed:
<
<
  1. Edit the file ...boards/tools/CMSConf.pm
>
>
  1. Edit the file ...boards/tools/CMSConf.pm
 
    1. follow the instructions to edit the variables flist, bSQL and invDef.
Changed:
<
<
  1. Modify the database itself
>
>
  1. Modify the database itself
 
    1. change to directory ...boards
Changed:
<
<
    1. enter command
      $ sqlite3 test.db
    2. enter commands
      sqlite> alter table amc13 add column dna varchar(30)
      =sqlite3> .quit=
      (e.g.) to add column "dna"
>
>
    1. enter command
      $ sqlite3 test.db
    2. enter commands
      sqlite> alter table amc13 add column dna varchar(30)
      =sqlite3> .quit=
      (e.g.) to add column "dna"
  Test the new feature thoroughly. See me to replace the live database.
Line: 1637 to 1589
 
    • readIPs.py only reads 0's for IP address
    • applyConfig and storeConfig also seem to not be working
    • readNVMem does seems to be working.
Changed:
<
<
 > ./storeConfig.py --slot=1 --ip=192.168.1.148

>
>
 > ./storeConfig.py --slot=1 --ip=192.168.1.148

 Storing IP addresses to board in slot 1 from host 192.168.1.41 Unable to send RAW command (channel=0x7 netfn=0x32 lun=0x0 cmd=0x40 rsp=0xc3): Timeout substr outside of string at ./config_tools/amc13config line 137. Use of uninitialized value in split at ./config_tools/amc13config line 137. Use of uninitialized value in multiplication (*) at ./config_tools/amc13config line 140. Use of uninitialized value in multiplication (*) at ./config_tools/amc13config line 140.
Changed:
<
<
Configuration Too Large 38 > 0 (with header) at ./config_tools/amc13config line 140.
>
>
Configuration Too Large 38 > 0 (with header) at ./config_tools/amc13config line 140.
 

2014-04-28, Dave

Line: 1704 to 1656
 Dan moved the uTCA crate into a small rack borrowed from Ed.

HOWTO set fan speeds on the crate:

Changed:
<
<
[cms2] /home/hazen > telnet 192.168.1.41

>
>
[cms2] /home/hazen > telnet 192.168.1.41

 Trying 192.168.1.41... Connected to 192.168.1.41. Escape character is '^]'.
Line: 1714 to 1664
  Welcome to NAT-MCH
Changed:
<
<
nat> fan_ctl
>
>
nat> fan_ctl
 FAN control: print help menu: 0 get fan properties: 1
Line: 1754 to 1703
  FED: 0 EvN: 0da000 BcN: 224 OrN: 0002bcd2 TTS: 0/0 EvTyp: 1 CalTyp: 0 Size: 236 UHTR 1 [ 444] EvN 0da000 BcN 224 OrN 13 FED: 0 EvN: 0dc000 BcN: a78 OrN: 0002c1ac TTS: 0/0 EvTyp: 1 CalTyp: 0 Size: 236
Changed:
<
<
UHTR 1 [ 444] EvN 0dc000 BcN a78 OrN 0d
>
>
UHTR 1 [ 444] EvN 0dc000 BcN a78 OrN 0d
 
  • Retesting SN42 with new uHTR firmware:
    • System works with AMC13 SN42 w/ old firmware
    • Problem related to resets and link disconnects (make sure to disable link between amc13 and uHTR before removing hardware)
Line: 1805 to 1755
 
  • confirm that #34 doesn't power up in our crate. MMC complains about power out of spec and requests payload power shutdown.

Combined working parts of broken boards (SN39 T2 abd SN34 T1). MCH info of combination in BU crate:

Changed:
<
<
nat> show_fru

>
>
nat> show_fru

  FRU Information:
Line: 1819 to 1769
  41 CU2 M4 VT VT095 50 PM1 M4 VT UTC010 ======================================
Changed:
<
<
nat> show_sensorinfo 12
>
>
nat> show_sensorinfo 12
 Sensor Information for AMC 8 ==================================================== # SDRType Sensor Entity Inst Value State Name
Line: 1837 to 1787
 

Capacitor on SN39 T1 was found to be causing short and was replaced. MCH printout while in Cornell crate:

Changed:
<
<
FRU Information:

>
>
FRU Information:

 
FRU Device State Name ======================================
Line: 1849 to 1799
  41 CU2 M4 VT VT095 51 PM2 M4 VT UTC010 ======================================
Changed:
<
<
nat> show_sensorinfo 9
>
>
nat> show_sensorinfo 9
 Sensor Information for AMC 5 ============================================================== # SDRType Sensor Entity Inst Value State Name
Line: 1906 to 1858
 
    • Removed insulating material to allow crate temperature to cool, while measuring clock temperature
    • Data: ClockTestCrateTemp.xlsx
Changed:
<
<
>
>
 
Changed:
<
<
>
>
 
Changed:
<
<
>
>
 

2013-06-26, dickens, dzou

  • Clock Test on input to mLVDS on SN 43:
    • Characteristic exponential curves. Maximum shift ~170 ps. Compared to maximum shift of ~100 ps on SN 33 board.
Changed:
<
<
>
>
 
  • Clock Test on input to mLVDS on SN 43 w/ temperature readout on U2:
    • Characteristic exponential curves. Maximum shift ~250 ps. Compared to maximum shift of ~100 ps on SN 33 board.
Changed:
<
<
>
>
 
  • Clock Test on input to mLVDS on SN 43 /w controlled temperature via resistor on U2. Notes:
    • AMC13 booted up at 0 s, U2 chip allowed to reach thermal eq.
Line: 1926 to 1878
 
    • Begin heating U2 to 40 at 1600 s
    • Begin heating U2 to 45 at 2468 s
Changed:
<
<
clockdelaytest_inputofU25.jpg
>
>
clockdelaytest_inputofU25.jpg
  ***Clock delay values normalized to U2 thermal eq. value (at ~600 s)
Line: 1940 to 1892
 
    • Took out SFP, cool down for 5 min
    • Put back SFP and took delay measurements
    • Barring the first measurement (directly after power on), measurement are within 3 ps of 195 ps delay (graph below)
Changed:
<
<
>
>
 

2013-06-25, dickens, dzou

  • 40 MHz and 900 mV peak to peak square. Testing probe parts:
Line: 1954 to 1906
 
    • Probe on input to U3, Temperature control on U3
    • Delay measured at various temperatures: 30, 35, and 40 Celcius
Changed:
<
<
>
>
 
  • Clock Delay test w/ temperature set at 40 deg C, power off for roughly 8 min, while keeping chip at 40 deg C. Turning on board still gives exponential Clock shift:

Plot of Delay plotted against time after power on

Changed:
<
<
>
>
 

2013-06-24, dickens, dzou

Line: 1968 to 1920
 
    • U2 covered in heat sink compound and held in thermal contact with thermistor
    • Thermistor connected to arduino provides temperature readout which goes to laptop
Deleted:
<
<
 Data sheet:
Changed:
<
<
tempU2_1.jpg

>
>
tempU2_1.jpg
 
  • ***Notes on data:
    • thermistor place in contact with chip at ~20 s
Line: 1990 to 1938
  Plot of clock phase at various power off times
Changed:
<
<
>
>
 
  • Study datasheets for tempco or phase/delay specs
    • ADN2814: no obvious information, but it's pretty long and detailed so I may have missed something
Line: 2006 to 1954
  Plot of clock phase at various power off times
Changed:
<
<
>
>
 

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.
Line: 2021 to 1969
  Plot of clock phase at various power off times
Changed:
<
<
>
>
 
  • Second probe location (independent from above) Moved probe to output of SFP receiver for TTC input (two vias next to U2 on T1).
    • Repeat power-cycle tests
Line: 2044 to 1992
 
    • Phase shift after 1 hour of power on: 4.524
Plot of clock phase at various power off times
Changed:
<
<
>
>
 

2013-06-11 dzou, hazen

Line: 2062 to 2010
 
Changed:
<
<
>
>
  Plot of a few test runs. Results are similar in magnitude to those seen at CERN.
Line: 2092 to 2038
  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:
Added:
>
>
 
Changed:
<
<
192.168.1.41
>
>
192.168.1.41
 MMC IPMI commands for reading an AMC13 in slot 3 (IPMB 0x76)
  • Read Spartan Address

Line: 2293 to 2241
  ( Anything else will just return to the original menu )
Changed:
<
<
Selection : [-1] 7
>
>
Selection : [-1] 7
  If you now send L1As to the uHTR, it produces events! Very good!
Line: 2370 to 2317
 q $ DCCdiagnose.exe >ttc/trig 1
Changed:
<
<
TTC L1A source set to 1 (panel input)
>
>
TTC L1A source set to 1 (panel input)
  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).
Line: 2406 to 2351
  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
Changed:
<
<
K Char Abort [0066]: 00000000 00000060 00000000 0000349b 00000000 000001b9 00000000 000012fe 00000000 000014cd 00000000 000000f5
>
>
K Char Abort [0066]: 00000000 00000060 00000000 0000349b 00000000 000001b9 00000000 000012fe 00000000 000014cd 00000000 000000f5
  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.
Line: 2411 to 2355
  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.
Deleted:
<
<

 

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
Changed:
<
<
# net interface 0

>
>
# net interface 0

 export SYSCFG_IFACE0=y export INTERFACE0="eth0" export IPADDR0="192.168.2.2"
Line: 2447 to 2386
 Attempting an initial installation of the VadaTech Commercial MCH card for the uTCA crate.

Procedure:

Changed:
<
<
  1. Install the VadaTech module in the MCH2
  2. 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
  3. Relevant Documents are...
>
>
  1. Install the VadaTech module in the MCH2
  2. 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
  3. Relevant Documents are...
 
Changed:
<
<
  1. 10/100 Ethernet has the default IP address 192.168.1.252, which conflicts with our IP assignment scheme for the AMC13s.
  2. According to the 'Getting Started Guide', the default IP address of the GbE is 192.168.40.250. Unsuccessful ping to this address.
  3. 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
  4. Despite my not being able to ping the GbE, I am going to try and connect anyway, as the documentation suggests.
>
>
  1. 10/100 Ethernet has the default IP address 192.168.1.252, which conflicts with our IP assignment scheme for the AMC13s.
  2. According to the 'Getting Started Guide', the default IP address of the GbE is 192.168.40.250. Unsuccessful ping to this address.
  3. 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
  4. Despite my not being able to ping the GbE, I am going to try and connect anyway, as the documentation suggests.
 
      [cms2] /home/chill90 > ssh root@192.168.40.250
      ssh: connect to host 192.168.40.250 port 22: Connection timed out
Line: 2464 to 2403
 
ssh
connect to host 192.168.40.250 port 22: Connection timed out Not surprisingly, no luck here. I get similar results if I try and access the IP address via a web browser
Changed:
<
<
  1. Next try connecting via the 10/100 Ethernet Port at 192.168.1.252. This pings successfully!
  2. Eric has now take over.
  3. TelNet into the card successfully.
    • > telnet 192.168.1.252
>
>
  1. Next try connecting via the 10/100 Ethernet Port at 192.168.1.252. This pings successfully!
  2. Eric has now take over.
  3. TelNet into the card successfully.
    • > telnet 192.168.1.252
 
    • Username: root
    • Password: root
Changed:
<
<
  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
    2. net interface 0 is the 10/100 Ethernet port. Edit IPADDR0 and/or NETMASK0 and/or BROADCAST0 as desired
    3. net interface 1 is the GbE port. Edit IPADDR1 and/or NETMASK1 and/or BROADCAST1 as desired
    4. 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
    5. Power cycle the MCH for the changes to take effect

>
>
  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
    2. net interface 0 is the 10/100 Ethernet port. Edit IPADDR0 and/or NETMASK0 and/or BROADCAST0 as desired
    3. net interface 1 is the GbE port. Edit IPADDR1 and/or NETMASK1 and/or BROADCAST1 as desired
    4. 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
    5. Power cycle the MCH for the changes to take effect
 

2012-10-26, hazen

Line: 2487 to 2424
 Some small details are likely to change, but the concept will remain.

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

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

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

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

# read Virtex IP address (bus addr byte determined empirically!)

Changed:
<
<
> ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x34 1 0 7 4
>
>
> ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x34 1 0 7 4
 f7 01 a8 c0

Changing the address:

Changed:
<
<
# set spartan address low byte to 128
> ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x33 0 0 7 1 0x80

>
>
# 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
Changed:
<
<
> ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x33 1 0 7 1 0x81
>
>
> ipmitool $IPMITOOLARGS -t 0xa4 raw 0x32 0x33 1 0 7 1 0x81
 
Changed:
<
<
[cms2] /home/hazen > ping 192.168.1.128
>
>
[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
Line: 2548 to 2478
  Found one! AMC13 Data is here. uHTR DAQ spy output:
Changed:
<
<
> spy

>
>
> spy

  0000 2 00ff 0001 3 ffff Event number 16777215 (0xffffff) 0002 3 8000
Line: 2577 to 2502
 At 1kHz fixed trigger rate for 1s, take some data. (here: warning! binary file).

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

Changed:
<
<
Starting to read file...

>
>
Starting to read file...

 First EvN is 1 (0x000001) AMC13 EvN = 0x00000012 uHTR(10) EvN = 0x00451112 !! AMC13 EvN = 0x0000004e uHTR(4) EvN = 0x0045114e !!
Line: 2588 to 2511
 

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

Changed:
<
<
AMC13 EvN = 0x00000012  uHTR(10) EvN = 0x00451112 !!

>
>
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
Line: 2626 to 2547
  Below is a raw dump of the data from the AMC13 excerpted. (deadbeef and following word count added by software). Note the 4511 ffff
Changed:
<
<
000770 deadbeef 0000001a 1d500008 51000012

>
>
000770 deadbeef 0000001a 1d500008 51000012

 000780 008a7470 00000000 00000010 00170410 000790 00000000 00000000 0000c00c 00000000 0007a0 00000000 0000c00b 00000412 bbee8000
Line: 2644 to 2563
 000840 ffff2000 13080000 766b0000 a000000d
Deleted:
<
<
 

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:

Changed:
<
<
0x10 LDC_accept_cntr

>
>
0x10 LDC_accept_cntr

 0x11 LDC_abort_cntr 0x12 LDC_ACK_cntr 0x13 LDC_event_cntr
Line: 2737 to 2644
 

2012-07-11, hazen

Add two lines below to UCF and recompile per Wu's suggestion:

Changed:
<
<
  NET "*/DAQ_Link_wu/UsrClk" TNM_NET = "DAQ_UsrClk";

>
>
  NET "*/DAQ_Link_wu/UsrClk" TNM_NET = "DAQ_UsrClk";

  TIMESPEC "TS_DAQ_UsrClk" = PERIOD "DAQ_UsrClk" 8ns HIGH 50%;

MiniCTR2 Programming:

(instructions below from MN)

Changed:
<
<
  1) Program the 4.02 firmware bitfile from JTAG.

>
>
  1) Program the 4.02 firmware bitfile from JTAG.

  2) mCTR2tool.exe 192.168.115.254 -t uhtr
Changed:
<
<
3) select your device (1). Then FLASH -> PROGRAM (you'll need an MCS file)
>
>
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.
Line: 2763 to 2668
 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:

Changed:
<
<
[cms2] /home/hazen/work/uHTR_Firmware > telnet 192.168.1.11

>
>
[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

Changed:
<
<
nat> ifconfig
>
>
nat> ifconfig
 network interface nat0: IP address: 192.168.1.11 broadcast address: 192.168.255.255 netmask: 255.255.0.0
Changed:
<
<
nat>
>
>
nat>
 

2012-07-10, hazen

Line: 2801 to 2704
  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:
Added:
>
>
 
  $ source ~hazen/environ.sh
Changed:
<
<
$ /src/11_5_1/hcal/hcalUpgrade/amc13/bin/linux/x86_64_slc5/AMC13DaqTest.exe
>
>
$ /src/11_5_1/hcal/hcalUpgrade/amc13/bin/linux/x86_64_slc5/AMC13DaqTest.exe
 
cms1 (DCCdiagnose.exe) cms2 (AMC13DaqTest.exe) Notes
  en 5,11 Enable AMC inputs (will change to 0,10 at some point). Also resets AMC13
Line: 2834 to 2737
  ....
  1. af0 06f306f206f106f0 06f706f606f506f4
  2. b00 06fb06fa06f906f8 705f06fe06fd06fc
Changed:
<
<
  1. b10 0000000000000a00 a00003891aca0000

>
>
  1. b10 0000000000000a00 a00003891aca0000
 

2012-07-08, hazen

Line: 2899 to 2796
  HyperDAQ
Changed:
<
<
    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.
>
>
HyperDAQ

AMC13_AddressTable_S6/V6.txt

  Run Control
Changed:
<
<
    AMC13.cc/hh were updated to add startRun(), endRun(), AMCInputEnable(), nextEventSize(), readNextEvent().
>
>
startRun()

endRun()

AMCInputEnable()

nextEventSize()

readNextEvent()

 

2012-06-27, rohlf

Line: 2934 to 2836
  this will take 0x800 events in the memory and throw away all when the buffer is full.
Changed:
<
<
In general, the initialization and read out remains basically the same as with DCC2.
>
>
In general, the initialization and read out remains basically the same as with DCC2.
 

2012-05-24, rohlf

Added:
>
>
 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

Deleted:
<
<
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.
 
Added:
>
>
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:

Changed:
<
<
To install on a teststand (as daqowner) :

>
>
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)
Line: 2967 to 2867
 (it's in AMC slot 4) but doesn't help.

Note:

Changed:
<
<
  pwr_on [fru #]

>
>
  pwr_on [fru #]

  pwr_off [fru #]

where [fru #] is the fru number starting with 5 to16. That means if you

Line: 2977 to 2877
  Remembering wisdom of Tom Gorski:
Changed:
<
<
    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.
>
>
unless
  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.
Line: 2989 to 2887
  cms2: SLC5 updated, installation fine tuned, PyChips and microHAL installed for the "daq" user, all tested and works
Deleted:
<
<
 

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

Changed:
<
<
AMC13FlashProgramming
>
>
AMC13FlashProgramming
 page.

2011-12-02, hazen

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

Changed:
<
<
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).
>
>
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:
Changed:
<
<
  unzip the e-mail attachement somewhere

>
>
  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
Line: 3018 to 2913
  -- EricHazen - 02 Dec 2011
Added:
>
>
edf@raspberrypi:~ $ python3 ttttControl.py resetCount
TCDS counters reset
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000001
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000004
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000005
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x000000000000000D
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000023
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x0000000000000025
Done!
edf@raspberrypi:~ $ python3 ttttControl.py ttsReport
Iterating through TTS counter registers (100-1FF), searching for non-zero entries...
non-zero counter found on TTS reg 101: 0x00000000000000FF
non-zero counter found on TTS reg 108: 0x00000000000000FF
non-zero counter found on TTS reg 109: 0x000000000000002F
Done!

 
META FILEATTACHMENT attachment="tempU2_1.jpg" attr="" comment="" date="1372112366" name="tempU2_1.jpg" path="tempU2_1.jpg" size="53300" stream="tempU2_1.jpg" tmpFilename="/usr/tmp/CGItemp56673" user="dickens" version="1"
META FILEATTACHMENT attachment="clockdelaytest_inputofU25.jpg" attr="" comment="" date="1372714520" name="clockdelaytest_inputofU25.jpg" path="clockdelaytest_inputofU25.jpg" size="79827" stream="clockdelaytest_inputofU25.jpg" tmpFilename="/usr/tmp/CGItemp54095" user="dickens" version="1"
META FILEATTACHMENT attachment="Screenshot_-_01192016_-_103020_AM.png" attr="" comment="2016-01-19 A working FEROL at BU: Webpage 1" date="1453217509" name="Screenshot_-_01192016_-_103020_AM.png" path="Screenshot - 01192016 - 10:30:20 AM.png" size="29610" stream="Screenshot - 01192016 - 10:30:20 AM.png" tmpFilename="/usr/tmp/CGItemp12453" user="dgastler" version="1"
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback