<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear Hans,</p>
<p><br>
</p>
<p>writing into the register works fine (I tried it several times):</p>
<p><br>
</p>
<p></p>
<div>RIO4-MCAL-1 mbsdaq > rwdump -a0x33333350 -w16,0<br>
Address=0x33333350<br>
Raw-write done.<br>
RIO4-MCAL-1 mbsdaq > rwdump -a0x33333350 -w16,0<br>
Address=0x33333350<br>
Raw-write done.<br>
RIO4-MCAL-1 mbsdaq > rwdump -a0x33333350 -w16,0<br>
Address=0x33333350<br>
Raw-write done.<br>
RIO4-MCAL-1 mbsdaq > rwdump -a0x33333350 -w16,0<br>
Address=0x33333350<br>
Raw-write done.</div>
<div><br>
</div>
<div>I could now litter map_map with printf() outputs to see where execution of</div>
<div><br>
</div>
<div>
<div style="color:#cccccc; background-color:#1f1f1f; font-family:Consolas,'Courier New',monospace; font-weight:normal; font-size:14px; line-height:19px; white-space:pre">
<div><span style="color:#cccccc"> </span><span style="color:#9cdcfe">v560</span><span style="color:#cccccc">-></span><span style="color:#9cdcfe">sicy_map</span><span style="color:#cccccc">
</span><span style="color:#d4d4d4">=</span><span style="color:#cccccc"> </span><span style="color:#dcdcaa">map_map</span><span style="color:#cccccc">(</span><span style="color:#9cdcfe">v560</span><span style="color:#cccccc">-></span><span style="color:#9cdcfe">address</span><span style="color:#cccccc">,
</span><span style="color:#569cd6">MAP_SIZE</span><span style="color:#cccccc">, </span>
<span style="color:#4fc1ff">KW_NOBLT</span><span style="color:#cccccc">,</span></div>
<div><span style="color:#cccccc"> </span><span style="color:#b5cea8">0</span><span style="color:#cccccc">,
</span><span style="color:#b5cea8">0</span><span style="color:#cccccc">, </span><span style="color:#569cd6">MAP_POKE_ARGS</span><span style="color:#cccccc">(fixed_code),
</span><span style="color:#569cd6">MAP_POKE_ARGS</span><span style="color:#cccccc">(scale_clear));</span></div>
</div>
</div>
<div><br>
</div>
<div>is failing. Should I proceed this way? Or is there anything else that I could check?</div>
<div><br>
</div>
<div>(As I understand, the slightly different implementation of V560 on our running system is not indicative of a specific issue, but just due to fact that this is a deprecated version of NURDLIB. Right?)<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Best greetings</div>
<div>Günter<br>
</div>
<br>
<p></p>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
<b>Gesendet:</b> Mittwoch, 21. Februar 2024 15:28:01<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr.<br>
<b>Betreff:</b> Re: [subexp-daq] Report of a possible bug of the CAEN_V560 module</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Günter,<br>
<br>
The most important thing is that you get reasonable values with these <br>
reads, the actual values don't mean a whole lot.<br>
<br>
One of the manual reads that you did (ofs=0xfa) is what 'map_map' does <br>
for "poke reading". The macros<br>
<br>
MAP_POKE_ARGS(fixed_code), or the older<br>
MAP_POKE_ARGS(*v560->read, fixed_code)<br>
<br>
tell 'map_map' what address offset to poke, and it depends on each module.<br>
<br>
The next thing that happens in 'map_map' is the "poke writing". Could <br>
you try to write to the 'scale_clear' register next? That would be:<br>
<br>
rwdump -a0x33333350 -w16,0<br>
<br>
---<br>
<br>
In case you would like to look deeper in 'map_map', you can find it in <br>
module/map/map.c around line-number 103. It's not a very complicated <br>
function that does the following:<br>
<br>
-) Checks user-mapped memory, you don't need to worry about this, it's <br>
mainly for simulating module memory for tests.<br>
<br>
-) Performs the poke-read.<br>
<br>
-) Performs the poke-write.<br>
<br>
-) If it's a BLT mapping, asks the platform-specific code to do that <br>
without further tests.<br>
<br>
-) Otherwise times the poke registers many times to get an idea about <br>
the speed of every single-cycle access.<br>
<br>
If you want to dig even deeper, you can look in <br>
module/map/map_xpc_3310.c which is what is used in the most recent Linux <br>
Rio4's. It's mainly a wrapper around a proprietary black-box library, so <br>
not scary and scary at the same time.<br>
<br>
Best regards,<br>
Hans<br>
<br>
On 2024-02-21 14:32, Weber, Guenter Dr. wrote:<br>
> Dear Hans,<br>
> <br>
> <br>
> with the different register addresses it works.<br>
> <br>
> <br>
> RIO4-MCAL-1 mbsdaq > rwdump -a0x333333fa -r16<br>
> Address=0x333333fa<br>
> Raw-read value=0xfaf5<br>
> <br>
> <br>
> RIO4-MCAL-1 mbsdaq > rwdump -a0x333333fc -r16<br>
> Address=0x333333fc<br>
> Raw-read value=0x083a<br>
> <br>
> <br>
> RIO4-MCAL-1 mbsdaq > rwdump -a0x333333fe -r16<br>
> Address=0x333333fe<br>
> Raw-read value=0x01bc<br>
> <br>
> What can we learn from these numbers?<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> *Von:* Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> *Gesendet:* Mittwoch, 21. Februar 2024 12:43:06<br>
> *An:* Weber, Guenter Dr.<br>
> *Betreff:* Re: [subexp-daq] Report of a possible bug of the CAEN_V560 <br>
> module<br>
> Hmm, looks like address offset 0 is "not used", could you try <br>
> -a0x333333fa? Or fe and fc at the end,they should be some read-only <br>
> registers.<br>
> <br>
> <br>
> "Weber, Guenter Dr." <g.weber@hi-jena.gsi.de> skrev: (21 februari 2024 <br>
> 12:06:00 CET)<br>
> <br>
> Different VME slot of the V560 module, same result. :-(<br>
> <br>
> ------------------------------------------------------------------------<br>
> *Von:* subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag<br>
> von Weber, Guenter Dr. <g.weber@hi-jena.gsi.de><br>
> *Gesendet:* Mittwoch, 21. Februar 2024 11:40:25<br>
> *An:* Hans Toshihide Törnqvist; Discuss use of Nurdlib, TRLO II,<br>
> drasi and UCESB.<br>
> *Betreff:* Re: [subexp-daq] Report of a possible bug of the<br>
> CAEN_V560 module<br>
> <br>
> Dear Hans,<br>
> <br>
> <br>
> the output from manual reading of the module indeed shows a problem:<br>
> <br>
> <br>
> RIO4-MCAL-1 mbsdaq > rwdump -a0x33333300 -r16<br>
> Address=0x33333300<br>
> Raw-read value=rwdump: line 28: 593 Bus error <br>
> $PREFIX $f "$@"<br>
> <br>
> <br>
> The module was working with this address in the other DAQ system (as<br>
> we did not know the order of the individual switches, we set them<br>
> all to "3"). But I can take it our and put it in again at a<br>
> different slot, if maybe this particular slot has a hardware<br>
> problem. (But I never heard of such thing.)<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> *Von:* Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> *Gesendet:* Mittwoch, 21. Februar 2024 11:14:44<br>
> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber,<br>
> Guenter Dr.<br>
> *Betreff:* Re: [subexp-daq] Report of a possible bug of the<br>
> CAEN_V560 module<br>
> Dear Günter,<br>
> <br>
> map_map before mapping tries to read and write some given registers<br>
> with a "safe" but slower method of accessing registers, which is<br>
> called "poking" in nurdlib. Maybe the method of access on the rio4<br>
> you have is not safe enough and one of the two pokes fails horribly...<br>
> <br>
> Could you please double check the module address? Could you also try<br>
> using bin/rwdump to read any register in the v560 to see if it's<br>
> accessible at all and not a problem with the module implementation<br>
> in nurdlib?<br>
> <br>
> Something like bin/rwdump -a0x33333300 -r16<br>
> <br>
> Actually the address 0x33333300 looks weird to me, maybe it should<br>
> be 0x33330000?<br>
> Also for reading, try register offsets fa, fc, fe, with 16 bits<br>
> accesseses, they should have some interesting values.<br>
> <br>
> Cheers,<br>
> Hans<br>
> <br>
> <br>
> "Weber, Guenter Dr." <g.weber@hi-jena.gsi.de> skrev: (21 februari<br>
> 2024 10:18:29 CET)<br>
> <br>
> Dear Hċkan,<br>
> <br>
> <br>
> thanks for the hint to flush and sleep. Indeed, I now see that<br>
> the crash happens in init_slow of V560 at this line:<br>
> <br>
> <br>
> v560->sicy_map=map_map(v560->address, MAP_SIZE, KW_NOBLT,<br>
> 0, 0, MAP_POKE_ARGS(fixed_code), MAP_POKE_ARGS(scale_clear));<br>
> <br>
> <br>
> Maybe the code is accessing/writing into a memory location that<br>
> it should better not touch?<br>
> <br>
> This problematic line is then followed by:<br>
> <br>
> <br>
> id=MAP_READ(v560->sicy_map, fixed_code);<br>
> <br>
> The corresponding line in the V560 code on the system that was<br>
> running with this module looks like this:<br>
> <br>
> <br>
> v560->sicy_map=map_map(v560->address, MAP_SIZE_MAX(*v560), KW_NOBLT,<br>
> 0, 0, MAP_POKE_ARGS(*v560->read, fixed_code),<br>
> MAP_POKE_ARGS(*v560->write, scale_clear));<br>
> <br>
> And is followed by:<br>
> <br>
> <br>
> mapped_ptr =map_get_mapped_ptr(v560->sicy_map);<br>
> v560->read=mapped_ptr;<br>
> v560->write=mapped_ptr;<br>
> <br>
> Maybe you already have an idea what causes the problem here?<br>
> <br>
> <br>
> I will now go to the system that was running with V560 and make<br>
> a push of the NURDLIB.<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> *Von:* subexp-daq <subexp-daq-bounces@lists.chalmers.se> im<br>
> Auftrag von Hċkan T Johansson <f96hajo@chalmers.se><br>
> *Gesendet:* Dienstag, 20. Februar 2024 20:13:32<br>
> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> *Betreff:* Re: [subexp-daq] Report of a possible bug of the<br>
> CAEN_V560 module<br>
> <br>
> Dear Günter,<br>
> <br>
> I took the files you provided and for comparison put them in a<br>
> branch<br>
> 'old_caen_v560'.<br>
> <br>
> git diff origin/old_caen_v560..origin/master<br>
> <br>
> however does not show anything which is suspicious to me. <br>
> Perhaps Hans<br>
> can spot something.<br>
> <br>
> Otherwise, the only idea I can come up with is to continue to<br>
> bisect the<br>
> code inside slow init.<br>
> <br>
> However, before that, I would suggest to add<br>
> <br>
> fflush(stdout); sleep(1);<br>
> <br>
> after each printf statement, such that one can be quite sure<br>
> that the<br>
> printout is not eaten when the RIO crash happens. I.e. that it<br>
> actually<br>
> had gotten further than shown by the prints.<br>
> <br>
> Best regards,<br>
> Hċkan<br>
> <br>
> <br>
> <br>
> <br>
> On Tue, 20 Feb 2024, Weber, Guenter Dr. wrote:<br>
> <br>
> > <br>
> > Dear friends,<br>
> > <br>
> > <br>
> > I now had a look at the system where the V560 was running. It was also setup<br>
> > by Bastian. And there the code for the V560 module is slightly different<br>
> > from the one included in the NURDLIB branch that I am using on the test<br>
> > system.<br>
> > <br>
> > <br>
> > Maybe you can have a look at it.<br>
> > <br>
> > <br>
> > I also could push the complete NURDLIB from this system, if this helps.<br>
> > <br>
> > <br>
> > <br>
> > <br>
> > Best greetings<br>
> > <br>
> > Günter<br>
> > <br>
> > <br>
> > <br>
> > <br>
> > ____________________________________________________________________________<br>
> > Von: subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Weber,<br>
> > Guenter Dr. <g.weber@hi-jena.gsi.de><br>
> > Gesendet: Dienstag, 20. Februar 2024 10:58:27<br>
> > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> > Betreff: [subexp-daq] Report of a possible bug of the CAEN_V560 module
<br>
> > <br>
> > Dear friends,<br>
> > <br>
> > <br>
> > I now grabbed a V560 module that was working fine in another DAQ system and<br>
> > put it into our test system.<br>
> > <br>
> > <br>
> > The main.cfg looks like this:<br>
> > <br>
> > <br>
> > log_level=spam # info, verbose, debug, spam<br>
> > <br>
> > CRATE("MCAL") {<br>
> > GSI_VULOM(0x03000000) {<br>
> > timestamp = true # needed to get timestamps in the data output<br>
> > # ecl=0..15<br>
> > }<br>
> > BARRIER<br>
> > CAEN_V560(0x333333300) {<br>
> > use_veto = true<br>
> > } <br>
> > # CAEN_V767A(0x03100000) {<br>
> > # }<br>
> > }<br>
> > <br>
> > Starting the DAQ now results in a freeze of the RIO4. A reset of the crate<br>
> > is necessary to talk to it again.<br>
> > <br>
> > <br>
> > The problem occurs in the first slow init of the V560 module. To find the<br>
> > exact line, I added some output to CRATE.C:<br>
> > <br>
> > <br>
> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.<br>
> > before push_log_level(module)<br>
> > before a_crate->module_init_id = module->id<br>
> > before module->props->init_slow(a_crate, module)<br>
> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)<br>
> > before module_init_id_mark(a_crate, module)<br>
> > before pop_log_level(module)<br>
> > 10: crate/crate.c:923: .Slow-init module[1]=CAEN_V560.<br>
> > before push_log_level(module)<br>
> > before a_crate->module_init_id = module->id<br>
> > before module->props->init_slow(a_crate, module)<br>
> > <br>
> > <br>
> > The CRATE.C code now looks like this:<br>
> > <br>
> > <br>
> > TAILQ_FOREACH(module, &a_crate->module_list, next) {<br>
> > if (NULL == module->props) {<br>
> > continue;<br>
> > }<br>
> > LOGF(info)(LOGL, "Slow-init module[%u]=%s.", module->id,<br>
> > keyword_get_string(module->type));<br>
> > printf("before push_log_level(module) \n");<br>
> > push_log_level(module);<br>
> > printf("before a_crate->module_init_id = module->id \n");<br>
> > a_crate->module_init_id = module->id;<br>
> > printf("before module->props->init_slow(a_crate, module) \n");<br>
> > if (!module->props->init_slow(a_crate, module)) {<br>
> > printf("before pop_log_level(module) \n");<br>
> > pop_log_level(module);<br>
> > printf("before goto crate_init_done \n");<br>
> > goto crate_init_done;<br>
> > }<br>
> > printf("before module_init_id_mark(a_crate, module) \n");<br>
> > module_init_id_mark(a_crate, module);<br>
> > printf("before pop_log_level(module) \n");<br>
> > pop_log_level(module);<br>
> > }<br>
> > <br>
> > Thus, to me it looks like the check "if (!module->props->init_slow(a_crate,<br>
> > module)) ..." is doing something quite horrible to the RIO4.<br>
> > <br>
> > <br>
> > This is unfortunate, because my original aim was to show that there is also<br>
> > a bug/mistake in readout_dt of the V560 module. But I did not come this far.<br>
> > <br>
> > <br>
> > Do you have any idea what might cause the freezing of the RIO4?<br>
> > <br>
> > <br>
> > <br>
> > <br>
> > Best greetings and many thanks<br>
> > <br>
> > Günter<br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> ><br>
> <br>
> <br>
</div>
</span></font>
</body>
</html>