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

[Håkan T Johansson]

On Fri, 24 May 2024, Weber, Guenter Dr. wrote:

> 
> 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.

--trig-status=0 apparently does that.
I have documented that in the --help text now.

Thanks!

Håkan




> 
> 
> 
> 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
> 
> 
> 
> 
>