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

[Weber, Guenter Dr.]

Dear friends,


I now grabbed a V560 module that was working fine in another DAQ system and put it into our test system.


The main.cfg looks like this:


log_level=spam # info, verbose, debug, spam

CRATE("MCAL") {
    GSI_VULOM(0x03000000) {
        timestamp = true # needed to get timestamps in the data output
    #   ecl=0..15
    }
    BARRIER
    CAEN_V560(0x333333300) {
        use_veto = true
    }
#   CAEN_V767A(0x03100000) {
#   }
}


Starting the DAQ now results in a freeze of the RIO4. A reset of the crate is necessary to talk to it again.


The problem occurs in the first slow init of the V560 module. To find the exact line, I added some output to CRATE.C:


10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.
before push_log_level(module)
before a_crate->module_init_id = module->id
before module->props->init_slow(a_crate, module)
LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)
before module_init_id_mark(a_crate, module)
before pop_log_level(module)
10: crate/crate.c:923: .Slow-init module[1]=CAEN_V560.
before push_log_level(module)
before a_crate->module_init_id = module->id
before module->props->init_slow(a_crate, module)


The CRATE.C code now looks like this:


    TAILQ_FOREACH(module, &a_crate->module_list, next) {
        if (NULL == module->props) {
            continue;
        }
        LOGF(info)(LOGL, "Slow-init module[%u]=%s.", module->id,
            keyword_get_string(module->type));
        printf("before push_log_level(module) \n");
        push_log_level(module);
        printf("before a_crate->module_init_id = module->id \n");
        a_crate->module_init_id = module->id;
        printf("before module->props->init_slow(a_crate, module) \n");
        if (!module->props->init_slow(a_crate, module)) {
            printf("before pop_log_level(module) \n");
            pop_log_level(module);
            printf("before goto crate_init_done \n");
            goto crate_init_done;
        }
        printf("before module_init_id_mark(a_crate, module) \n");
        module_init_id_mark(a_crate, module);
        printf("before pop_log_level(module) \n");
        pop_log_level(module);
    }


Thus, to me it looks like the check "if (!module->props->init_slow(a_crate, module)) ..." is doing something quite horrible to the RIO4.


This is unfortunate, because my original aim was to show that there is also a bug/mistake in readout_dt of the V560 module. But I did not come this far.


Do you have any idea what might cause the freezing of the RIO4?




Best greetings and many thanks

Günter



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240220/57ed3a60/attachment.html>