Starting a new run nearly immediately blocks
Summary
While debugging !10 (merged) and !11 (merged), many small issues preventing to take a run. No data is readout and the AMC13 goes to busy as soon as triggers start flowing.
Steps to reproduce
Start a run with !10 (merged) and !11 (merged) merged, using the regular state transitions:
- VFAT are not configured correctly, the default POR configuration is applied;
- None of the VFAT are set into run mode in "Running";
- The event builder input mask is reset to
0
during the "Start" action even if set manually after configuration; - The AMC13 is stuck in BSY.
What is the expected correct behavior?
The data acquisition should start seamlessly.
Environment
- Version used: 3fa70116 with !10 (merged) and !11 (merged) merged
- Operation System: CC7 on
gem904daq04
Possible fixes
Different issues have different origins:
-
VFAT are not configured correctly
The
HwOptoHybrid::configureVFATs
function calls the::vfat3::configureVFAT3s
RPC method with the~m_connectedMask
VFAT mask. SinceHwOptoHybrid::getConnectedVFATMask
is never called,m_connectedMask
is never set to a meaningful value. -
None of the VFAT are set into run mode in "Running"
No function call is performed during the "Start" action to set the VFAT into run mode.
-
The AMC13 is stuck in BSY
The AMC13 L1A buffer is overflowing, no event are built and no back-pressure is applied. That was traced down to the AMC event builder not being enabled (and therefore not sending any events) during the "Start" action. Since the AMC13 waits forever for an events from each of the AMC (no timeout), the AMC13 L1A buffer overflows.