Generic

"clearreadout" and "clear"
need to reset the TxLink and RxLink for XPM front-panel (note: have learned that RxLink reset can cause link CRC errors (see below) and have to do a TxLink reset to fix. so order is important). The TxLink reset causes the link to retrain using K characters
look for deadtime
check that the "partition" window (with the trigger-enable checkbox) is talking to the right XPM (currently "2" ... selects which XPM to use (across crates))
XPM is not configured to forward triggers ("LinkEnable" for that link on the XPM GUI)
L0Delay set to 99
DST Select (in PART window) set to "DontCare" (could be Dontcare/Internal)
check processes in lab3-base.cnf are running
run psdaq/build/psdaq/pgp/kcu1500/app/kcuStatus and kcuDmaStatus in kcuDmaStatus "blockspause" and "blocksfree" determine whether or not deadtime is set. if blocksfree drops below blockspause then it will assert deadtime. in hsd window "pgp last rx opcode" 0 means no backpressure, 1 means backpressure. Watch for locPause non zero which causes deadtime.
check for multiple drp executables
clearReadout broadcasts a message to receiving kcu's telling them to reset timing-header FIFOs.
if running "drp" executable, check that lane mask is correct
if events are showing up "sporadically" look for CRC errors from "kcuSim -s -d /dev/datadev_0". We have seen this caused by doing an XPM RxLink reset without a later TxLink reset.

HSD

HSD is not configured to do anything (Check the HSD config tab for no channels enabled)
if hsd timing frames are not being received at 926kHz (status here), click TxLink Reset in XPM window
The HSD configuration partition number does not match platform number in .cnf file (Check the HSD "base" tab)
also check that HEADERCNTL0 is incrementing in "status" tab of HSD cfg window.
in hsd window timepausecnt is number of clocks we are dead
in hsd expert window "full threshold(events)" sets threshold for hsd deadtime
in hsd status window "fex free events" and "raw free events" are the current free events.
in hsd status window "write fifo count" is number of timing headers waiting for HSD data to associate.
"pgp tx frame count" on hsd status goes up when we send a transition
check kcuStatus for "locPause" non-zero (a low level pgp FIFO being full). If this happens then: configure hsd, clear readout, reboot drp node with KCU