[subexp-daq] Question on trlo_ctrl with option --trig-status

[Weber, Guenter Dr.]

Dear Håkan,


to me it looks like


$VULOM4_CTRL --addr=$addr --trig-status


starts a never ending printout of the current status of the VULOM.

Is there a possibility to just get the status a single time and then stop the execution?

My intention is to check, after setting up the VULOM, when synchronization is done and it is safe to start the DAQ.



Many thanks and best greetings
Günter

________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Donnerstag, 22. Februar 2024 17:06
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] Report of a possible bug of the CAEN_V560 module


On Thu, 22 Feb 2024, Weber, Guenter Dr. wrote:

>
> Dear Hans,
>
>
> many thanks! And in particular for all the detailed explanations.
>
>
> For the VULOM "sleep 1" did not do the trick, but "sleep 10" worked. Is
> there any chance to ask the VULOM if it feels ready to do the job, instead
> of using a random waiting time?

Now there is!  Update trloii and recompile trlo_ctrl,

   --trig-status   will at the end show some extra lines:

Serial timestamp status:(0x000a8004) words:  4 badbits: 0 CHKsum:0x00
Serial timestamp: Sync: no  Bitstr. sync: no, had loss  Data ptn: no, had loss

Where it should say "Sync: ok" when the receiver has locked.

The 'had loss' and bad bits count can be cleared (when locked) by issuing
   "pulse = SERIAL_TSTAMP_FAIL_CLEAR"

> Also I noticed that when aksing the VULOM which firmware it is using, we get
> a slightly different reply than the actual firmware number:
>
> RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --read
> VULOM base address: 0x03000000
> hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is
> 0x3005e000.
> Performing command 'read'...
> VOLUM+0 => 0x14091f20
> VOLUM+RANGE_REG(0x800000) => 0x0000006a
> Released vme ptr.
> But the actual firmware number is 1409285e.
>
> For comparison should one look only at the first four hex numbers? Or is
> there more to take into account?

Yes, vulomflash --read reads at offset 0, and at that offset is also a
TRIVA module mimic, which only uses the low 16 bits however.  So the high
16 bits give part of the firmware hash.

> For the V560 module, misusing the bitmask for the counter resolved the
> issue. At the end of this mail, I attach the new log. Maybe you find
> something notable, but to me it looks fine now.
>
>
> Our next steps would be as follows:
>
>
> 1) Wait for you to implement the bugfixes of the last days into NURDLIB.
>
> 2) Setting up the test system with the most recent version of NURDLIB and
> checking, if our minimal system with VULOM and V560 is now running smoothly.
>
> 3) Hammering the V767 TDC into NURDLIB.
>
> 4) Once we have achieved this, we would go back to testing the SIS3316
> modules.
>
>
>
> Best greetings
>
> Günter

Cheers,
Håkan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240524/71bb3b3a/attachment.html>