The FEE Server Control Engine of the ALICE-TRD - Westfälische ...

5 The FEEServer Control Engine
the optical power of the diode is interesting because this information can be used to
localize problems when the GTU gets only a weak optical input signal.
5.4.6 Memory Tests
Three memory tests are available to check the internal memory of the CPUs in the MCMs.
First, initial patterns of 0xABCD are written into memory areas starting at 0xF000 of each
CPU. Then the patterns are read back by a second CPU: CPU0 is read out by CPU1, CPU1
is read out by CPU2, CPU2 is read out by CPU3 and CPU3 is read out by CPU0. Each time
the read out pattern differs from the expected pattern, the address of the memory at fault
is subsequently stored in other memory areas of the CPUs. At the end of the tests these
memory areas are read out and a detailed report is created, containing the addresses of
all damaged memory areas.
The tree memory tests for DMM, DDD, and IMM memory (for detail see [A + 05])
mainly differ in the memory addresses that are checked. Additionally, in case of the
DMM and DDD test, the board merger and half chamber merger are allowed to have
memory errors. Therefore they are not checked during DMM and DDD test.
5.4.7 Network Interface Test
The Network Interface test checks the connections of the Readout Tree (see sec. 4.3.6).
First a bit pattern is written to a memory area of each MCM via SCSN Bus and it is
checked that this was done successfully. Afterwards a pretrigger frame is sent to each
MCM triggering the data transfer to the MCMs in the next higher level of the Readout
tree. Then the memory area where the received data are stored is read out via the SCSN
Bus and compared with the expected pattern. This procedure is repeated with different
bit patterns to increase the sensitivity of this test.
Only the spare and the parity line of each connection is not checked with the procedure
described above. Therefore in a second pass two other lines are configured as spare line
and parity line. After the reconfiguration the complete test is repeated.
Every difference between the received and expected pattern is reported as an error.
Additionally the exact position of the broken line is determined and reported.
5.5 Error Handling and the Logging System
5.5.1 Error Handling in the Control Engine
The error handling in the control engine is based on the exception mechanism of C++.
Each time something unexpected happens which the current function cannot handle it
executes the code in listing 5.5. Usually one would create an instance of a class which
stores information about the error and then call the C++ function throw() with the class
as parameter. However, the ARM cross compiler used to compile the control engine for
the DCS board does not support this technique. It can handle only the build in types of
variables. Therefore a different implementation was chosen.
The class ErrorInfo is implemented as a singleton class. It is derived from the C++ class
ostringstream to get streaming functionality. Each time an error occurs, first the error type
is set (line one in listing 5.5). At the moment 19 different error types are defined but the
71