WIB Troubleshooting

  • Make sure the WIB is powered on (and that the power supply output is enabled)

  • Errors in the DTS CDS, like LOL=1 or LOS=1 could mean the timing signal isn't getting to the WIB. It could also mean that you are looking for the timing signal in the wrong place, i.e. the backplane instead of the front panel. If it takes a long time to initialize, that could mean the connection isn't good (like when you put a 8 deg fiber into a 0 deg interface)

  • You can control the timing with the commands here: ~np04daq/notes/timing.txt and the WIB timing status with the BUTool command: status 10 DTS DTS_SI5344 DTS_CDS

FEMB Troubleshooting

  • If you aren't getting data from the FEMBs on the WIB, and random data from spy_femb, please try the following command.
"fread 1 VERSION_ID" to see if it properly returns the FEMB FW version and then do "fread 1 TIME_COMPILED" to see if it give a number different than the VERSION ID. If this all works then we know the FEMBs are up and the issue is someplace else.

Reporting Problems to the Elog

Please describe the problem and attach the output of one of the following commands to an elog entry:

cd /nfs/sw/wib/WIBSoftwareTrunk
source env.sh
cd scripts/
dump_vst_wib_rce.sh # for VST RCE WIB
dump_vst_wib_felix.sh # for VST FELIX WIB
dump_coldbox_wibs.sh # for cold box WIBs

artDAQ Exception Glossary

Invalid name
you tried to use a register name that isn't in the register table

Bad File
you can't access the BUTool table files, source env.sh

Convert State

  • On configuring:
    • If the timing system is locked in the RUN state:
      1. Start out in WAIT_FOR_SYNC 0x0
      2. Once receive a sync (or two) it goes into IN_SYNC
        • If another sync comes at the wrong time go into OUT_OF_SYNC
    • if the timing system is not locked (W_RDY 0x6?) state:
      • Convert state is IDLE
  • If in local clock mode, then there are corresponding FAKE_* modes

Timing System Endpoint State PDTS_STATE

Hex Code Binary Code Name Description
0x0 0b0000 W_RST Starting state after reset
0x1 0b0001 W_SFP Waiting for SFP LOS to go low
0x2 0b0010 W_CDR Waiting for CDR lock
0x3 0b0011 W_ALIGN Waiting for comma alignment, stable 50MHz phase; CDR is locked but data is bad
0x4 0b0100 W_FREQ Waiting for good frequency check
0x5 0b0101 W_LOCK Waiting for 8b10 decoder good packet
0x6 0b0110 W_RDY Waiting for time stamp initialisation
0x8 0b1000 RUN Good to go
0xA 0b1100 ERR_R Error in rx
0xB 0b1101 ERR_T Error in time stamp check

The system should quickly cycle through some of these states. If an endpoint is stuck in one of these states, then:

Red means really bad, possible hardware problem. Check timing system is powered on and cables are connected. Could mean no timing signal or that the CDR has failed to lock

Yellow means time stamps syncs aren't being sent. Check timing system configruation (software problem). Short term fix is to login to np04-srv-012 and run:

source /nfs/sw/timing/pro/software/timing-board-software/tests/env.sh
pdtbutler master DUNE_FMC_MASTER send TimeSync
pdtbutler master DUNE_FMC_MASTER send TimeSync

Green means good. This is how it should be

-- JustinHugon1 - 2017-11-02

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r12 - 2018-03-14 - JustinHugon1
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CENF All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback