...

Matt explained that the KCU's Tx link was down while its Rx link was up, so transitions could be received, but the XPM's deadtime signal was latched asserted due to the KCU to XPM link being down.  He further traced the KCU's Tx link being down is due to "the reset that gets asserted when loading the datadev driver that causes the timing link to go into this unrecoverable state."  He contacted Ben for a proper fix.

UNSOLVED: after power cycling the timing system the opal stopped working.  This log file shows an _last field that doesn't exist: /reg/neh/home/cpo/2020/07/27_14:41:20_drp-tst-dev003:tmoopal_0.log.  I think that's because in cameralink_gateway/surf/protocols/clink/_UartOpal1000.py the _last attribute is only created if things are working.  Starting up the standalone rogue gui (python git/cameralink-gateway/software/scripts/devGui.py --camType Opal1000) the timing link appears to be OK, but HSIO->PgpMon[0]->RxPhyReady (I believe this is the link to the camera) is toggling to False once per second and RxLocalLinkReady/RxRemLinkReady are false.  In a previous time this occurred Larry said that there is a watchdog that tries to reset the link once per second, hence the toggling.  Tried:

• hitting rx/tx link resets in PgpMon[0]
• ConfigureXpmMini->ConfigLCLSTimingV2 (don't think this can affect the link to the camera)
•  Tx/Rx link resets in rpm (don't think this can affect the link to the camera)
• powercycle the drp node (drp-tst-dev003) and repeat the above
• loading a yaml file (git/cameralink-gateway/software/config/Opal1000.yml)

Feels like we need to power cycle the FEB?

AMI

Got the following when running ami.cnf against a running tmo.cnf system that includes HSDs:

...