Project

General

Profile

Current hardware/software issues

Unsolved

USB communication to logic board doesn't work after power up

Sometimes USB comms (configure, slow controls) don't work after power up with messages like:

sendMessageViaUSB : Did not receive /‘>/‘ after 15loops

A power cycle resolves this. It needs investigating.

Never get data back from logic boards

Sometimes mid way through a run/script we suuddenly stop ever getting data back from triggers. This can only be solved by a power cycle. Further investigation shows "clock not locked" errors in SetupFrontEnd.py, so it seems that the logic board loses lock on the GLIB clock. I don't know the source of this error yet (could be GLIB or LB end).

Logic board spill_num / time reset sometimes every without C5 reset commands

The LB spill_num and time values (as packed into the data stream) are reset using C5 commands (0xE,0xF). However, when we do SetupFrontEnd.py with these two commands removed, ~ 2/3 of the time these numbers reset anyway, but the other ~1/2 of the time they don't. Don't know why, although there are other reset commands in this script.

Clock not locked

Sometimes get problems during setup/configure like:

Checking for lock on external clock

Power cycling the logic board fixes this.

This now seems to be solved, although you will still see it if the fiber to the logic board is connected after power on.

Strange replies over USB line

Sometimes get unexpected replies via USB line. One common example:

CDR setting : 6 CDR edges : 1 CDR histo : 1
lb : writeReg : Received reply "0x088F0000" when none was expected

Re-running setup/configure a few times seems to solve it (without power cycle). Needs investigating (probably getting reply to different command, so have timing issue).

Interference between Arduinos

We have seen a case where two Arduios seem to interference despite reporting that they are talking to different devices (e.g. ACM0,AMC1 etc). The symptoms are a script talking to the arduin (e.g. LV scripts) hanging, or getting messages back from the wrong arduino.

We don't know the cause of this issue yet. Although unplugging and replugging the USBs (and for the old LV pulling out the power first and reattaching only after) seems to solve it.

Solved

GLIB spillno register resets

The GLIB spillno register counts the number of data events from logic boards the formatter finds in the 8b10b FIFOs (and then puts in RAM). So it should count once per logic board per trigger. Sometimes it seems to reset randomly during runs/scripts. It turns out that sometimes there seems to be an IPBus write error where it writes to address 0 rather than the desired address, and address 0 was being used for global_reset within the GLIB firmware (which resets spillno).

Solved now, never use IPBus nodes with address 0x0.

LV commands not been executed

If sending LV commands (e.g. using SendLVCommands.py) does not produce the expected result (e.g. LV on/off)., check the script output for the arduino response. It should be something like:

OK 1

If instead you see something like:

+ve supply voltage 0.79V
+ve supply current 0.10A
-ve supply voltage 0.13V
-ve supply current 0.05A

This means that you are instead talking to the LV current monitor arduino, no the LV control arduino. Either unplug the current monitor arduino from USB, or otherwise resolve the USB device information in your scripts.

Logic board receives trigger but does not return data

If logic board registers that a trigger has been received (e.g. EB_triggers_received in reg 0x21 increments), but no data is returned and the logic boards registers show the EB sent no event (e.g. EB_trailers_sent in reg 0x22 stays at 0), it probably means you have issues with your enabled TDC mask compared to the TDCs themselves.

E.g. the bits that are "1" in "TDC_CTRL_enable_mask" don't correspond fully to those TDCs that are enabled in their own register (0x0).