Skip to content

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

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. Since HwOptoHybrid::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.