[subexp-daq] Report of a possible bug of the CAEN_V560 module

[Hans Toshihide Törnqvist]

On 2024-02-22 10:04, Weber, Guenter Dr. wrote:
> Dear friends,
> 
> after the bug in map_map was fixed, the freeze does not happen again. 
> Very good!

Thanks for testing, I'm saving that fix myself!

> Now back to my original concern regarding the V560 module ...
> 
> readout_dt looks like this:
> 
> uint32_t
> caen_v560_readout_dt(structCrate*a_crate, structModule*a_module)
> {
>      (void)a_crate;
> LOGF(spam)(LOGL, NAME" readout_dt {");
> a_module->event_counter.value++;
> LOGF(spam)(LOGL, NAME" readout_dt(ctr=0x%08x) }",
> a_module->event_counter.value);
> return0;
> }
> 
> The module counter is incremented by one every time readout_dt is 
> executed. This results in a problem in crate.c:
> 
> diff_module=COUNTER_DIFF(*module->crate_counter,
> module->event_counter, module->this_minus_crate);
>              /* TODO: Clean this. */
> shadow_counter.value=
> module->shadow.data_counter_value;
> shadow_counter.mask=module->event_counter.mask;
> diff_shadow=COUNTER_DIFF(*module->crate_counter,
> shadow_counter, module->this_minus_crate);
> 
> create_do_shad=!crate_get_do_shadow(a_crate);
> printf("%s: diff_module: %u, module_crate_counter: %u, 
> module_event_counter: %u, module_this_minus_crate: %u\n", 
> keyword_get_string(module->type), diff_module, 
> (*module->crate_counter).value, (module->event_counter).value, 
> module->this_minus_crate);
> if(0==diff_module&&
>                  ( create_do_shad||
> NULL==module->props->readout_shadow||
> 0==diff_shadow)) {
> ok=1;
> printf("%u\n", ok);
> break;
>              }
> getchar();
> 
> When the difference between (*module->crate_counter).value and 
> (module->event_counter).value is evaluated the later was already 
> incremented as readout_dt for the module was already executed while the 
> former counter was not incremented.

The crate counter should have been incremented by the readout function 
that calls 'crate_readout_dt'. If I remember correctly you used the 
r3bfuser, so somewhere in fuser.c there's a function fuser_readout which 
calls crate_tag_counter_increase. The crate counter increment is 
"abstracted" away a bit, due to module tagging and multi-event support 
when it can increase by an arbritary value between events.

> This is the output:
> 
> CAEN_V560: diff_module: 4294967295, module_crate_counter: 0, 
> module_event_counter: 1, module_this_minus_crate: 0
> 
> Note that diff_module shows the result of an "0 - 1" operation when 
> working with unsigned integers.

Looks like the crate counter stays still on 0 indeed. Do you have a 
snippet of the drasi log around this error message?

> The original version of the crate.c code would now again execute 
> readout_dt of module V560, thus incrementing the module counter another 
> time. Thus, diff_module would be "0 - 2". This would repeat until the 
> timeout condition a bit later in the code is reached.
> Then the modules would be re-initialized, thus setting 
> (module->event_counter).value of V560 back to zero. But the crate 
> counter would be incremented. Thus, by shear luck the next try of the 
> same test would have (*module->crate_counter).value and 
> (module->event_counter).value both equal to 1. And from this point the 
> DAQ is running as intended.

It sounds to me like the old version was very broken and should be 
buried, deep.

Best regards,
Hans

> Ok, I hope the explanation was clear and I understood correctly what is 
> happening.
> 
> Best greetings
> Günter