<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>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:14pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Dear friends,</p>
<p><br>
</p>
<p>after the bug in map_map was fixed, the freeze does not happen again. Very good!</p>
<p><br>
</p>
<p>Now back to my original concern regarding the V560 module ...</p>
<p><br>
</p>
<p>readout_dt looks like this:<br>
</p>
<p><br>
</p>
<p></p>
<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: #4ec9b0;">uint32_t</span></div>
<div><span style="color: #dcdcaa;">caen_v560_readout_dt</span><span style="color: #cccccc;">(</span><span style="color: #569cd6;">struct</span><span style="color: #cccccc;">
</span><span style="color: #4ec9b0;">Crate</span><span style="color: #cccccc;"> </span>
<span style="color: #d4d4d4;">*</span><span style="color: #9cdcfe;">a_crate</span><span style="color: #cccccc;">,
</span><span style="color: #569cd6;">struct</span><span style="color: #cccccc;"> </span>
<span style="color: #4ec9b0;">Module</span><span style="color: #cccccc;"> </span>
<span style="color: #d4d4d4;">*</span><span style="color: #9cdcfe;">a_module</span><span style="color: #cccccc;">)</span></div>
<div><span style="color: #cccccc;">{</span></div>
<div><span style="color: #cccccc;"> (</span><span style="color: #569cd6;">void</span><span style="color: #cccccc;">)</span><span style="color: #9cdcfe;">a_crate</span><span style="color: #cccccc;">;</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #569cd6;">LOGF</span><span style="color: #cccccc;">(spam)(</span><span style="color: #569cd6;">LOGL</span><span style="color: #cccccc;">,
</span><span style="color: #569cd6;">NAME</span><span style="color: #ce9178;">" readout_dt {"</span><span style="color: #cccccc;">);</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">a_module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">event_counter</span><span style="color: #cccccc;">.</span><span style="color: #9cdcfe;">value</span><span style="color: #d4d4d4;">++</span><span style="color: #cccccc;">;</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #569cd6;">LOGF</span><span style="color: #cccccc;">(spam)(</span><span style="color: #569cd6;">LOGL</span><span style="color: #cccccc;">,
</span><span style="color: #569cd6;">NAME</span><span style="color: #ce9178;">" readout_dt(ctr=0x</span><span style="color: #9cdcfe;">%08x</span><span style="color: #ce9178;">) }"</span><span style="color: #cccccc;">,</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">a_module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">event_counter</span><span style="color: #cccccc;">.</span><span style="color: #9cdcfe;">value</span><span style="color: #cccccc;">);</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #c586c0;">return</span><span style="color: #cccccc;">
</span><span style="color: #b5cea8;">0</span><span style="color: #cccccc;">;</span></div>
<div><span style="color: #cccccc;">}</span></div>
</div>
<p></p>
<p><br>
</p>
<p>The module counter is incremented by one every time readout_dt is executed. This results in a problem in crate.c:</p>
<p><br>
</p>
<p></p>
<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;">diff_module</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">=</span><span style="color: #cccccc;"> </span>
<span style="color: #569cd6;">COUNTER_DIFF</span><span style="color: #cccccc;">(</span><span style="color: #d4d4d4;">*</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">crate_counter</span><span style="color: #cccccc;">,</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">event_counter</span><span style="color: #cccccc;">,
</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">this_minus_crate</span><span style="color: #cccccc;">);</span></div>
<div><span style="color: #6a9955;"> /* TODO: Clean this. */</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">shadow_counter</span><span style="color: #cccccc;">.</span><span style="color: #9cdcfe;">value</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">=</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">shadow</span><span style="color: #cccccc;">.</span><span style="color: #9cdcfe;">data_counter_value</span><span style="color: #cccccc;">;</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">shadow_counter</span><span style="color: #cccccc;">.</span><span style="color: #9cdcfe;">mask</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">=</span><span style="color: #cccccc;"> </span>
<span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">event_counter</span><span style="color: #cccccc;">.</span><span style="color: #9cdcfe;">mask</span><span style="color: #cccccc;">;</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">diff_shadow</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">=</span><span style="color: #cccccc;"> </span>
<span style="color: #569cd6;">COUNTER_DIFF</span><span style="color: #cccccc;">(</span><span style="color: #d4d4d4;">*</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">crate_counter</span><span style="color: #cccccc;">,</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">shadow_counter</span><span style="color: #cccccc;">,
</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">this_minus_crate</span><span style="color: #cccccc;">);</span></div>
<br>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">create_do_shad</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">=</span><span style="color: #cccccc;"> </span>
<span style="color: #d4d4d4;">!</span><span style="color: #dcdcaa;">crate_get_do_shadow</span><span style="color: #cccccc;">(</span><span style="color: #9cdcfe;">a_crate</span><span style="color: #cccccc;">);</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #dcdcaa;">printf</span><span style="color: #cccccc;">(</span><span style="color: #ce9178;">"</span><span style="color: #9cdcfe;">%s</span><span style="color: #ce9178;">: diff_module:
</span><span style="color: #9cdcfe;">%u</span><span style="color: #ce9178;">, module_crate_counter:
</span><span style="color: #9cdcfe;">%u</span><span style="color: #ce9178;">, module_event_counter:
</span><span style="color: #9cdcfe;">%u</span><span style="color: #ce9178;">, module_this_minus_crate:
</span><span style="color: #9cdcfe;">%u</span><span style="color: #ce9178;"> </span>
<span style="color: #d7ba7d;">\n</span><span style="color: #ce9178;">"</span><span style="color: #cccccc;">,
</span><span style="color: #dcdcaa;">keyword_get_string</span><span style="color: #cccccc;">(</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">type</span><span style="color: #cccccc;">),
</span><span style="color: #9cdcfe;">diff_module</span><span style="color: #cccccc;">, (</span><span style="color: #d4d4d4;">*</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">crate_counter</span><span style="color: #cccccc;">).</span><span style="color: #9cdcfe;">value</span><span style="color: #cccccc;">,
(</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">event_counter</span><span style="color: #cccccc;">).</span><span style="color: #9cdcfe;">value</span><span style="color: #cccccc;">,
</span><span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">this_minus_crate</span><span style="color: #cccccc;">);</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #c586c0;">if</span><span style="color: #cccccc;"> (</span><span style="color: #b5cea8;">0</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">==</span><span style="color: #cccccc;"> </span>
<span style="color: #9cdcfe;">diff_module</span><span style="color: #cccccc;"> </span>
<span style="color: #d4d4d4;">&&</span></div>
<div><span style="color: #cccccc;"> ( </span><span style="color: #9cdcfe;">create_do_shad</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">||</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #569cd6;">NULL</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">==</span><span style="color: #cccccc;"> </span>
<span style="color: #9cdcfe;">module</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">props</span><span style="color: #cccccc;">-></span><span style="color: #9cdcfe;">readout_shadow</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">||</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #b5cea8;">0</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">==</span><span style="color: #cccccc;"> </span>
<span style="color: #9cdcfe;">diff_shadow</span><span style="color: #cccccc;">)) {</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #9cdcfe;">ok</span><span style="color: #cccccc;">
</span><span style="color: #d4d4d4;">=</span><span style="color: #cccccc;"> </span>
<span style="color: #b5cea8;">1</span><span style="color: #cccccc;">;</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #dcdcaa;">printf</span><span style="color: #cccccc;">(</span><span style="color: #ce9178;">"</span><span style="color: #9cdcfe;">%u</span><span style="color: #ce9178;">
</span><span style="color: #d7ba7d;">\n</span><span style="color: #ce9178;">"</span><span style="color: #cccccc;">,
</span><span style="color: #9cdcfe;">ok</span><span style="color: #cccccc;">);</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #c586c0;">break</span><span style="color: #cccccc;">;</span></div>
<div><span style="color: #cccccc;"> }</span></div>
<div><span style="color: #cccccc;"> </span><span style="color: #dcdcaa;">getchar</span><span style="color: #cccccc;">();</span></div>
</div>
<br>
<p></p>
<p>When the difference between <span>(*module->crate_counter).value and <span>(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.</span></span></p>
<p><span><span><br>
</span></span></p>
<p><span><span>This is the output:</span></span></p>
<p><span><span></span></span><br>
</p>
<p><span><span></p>
<div>CAEN_V560: diff_module: 4294967295, module_crate_counter: 0, module_event_counter: 1, module_this_minus_crate: 0</div>
<div><br>
</div>
<div>Note that diff_module shows the result of an "0 - 1" operation when working with unsigned integers.</div>
<div><br>
</div>
<div>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.</div>
<div>Then the modules would be re-initialized, thus setting <span><span>(module->event_counter).value</span></span> 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
<span>(*module->crate_counter).value</span> and <span><span>(module->event_counter).value</span></span> both equal to 1. And from this point the DAQ is running as intended.</div>
<div><br>
</div>
<div>Ok, I hope the explanation was clear and I understood correctly what is happening.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Best greetings</div>
<div>Günter<br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
</span></span>
<p></p>
<p><br>
</p>
<div id="Signature">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt">----------------<br>
<br>
Günter Weber<br>
<br>
Helmholtz-Institut Jena<br>
Fröbelstieg 3<br>
07743 Jena<br>
Germany<br>
Phone: +49-3641-947605<br>
<a href="http://www.hi-jena.de" id="LPNoLP"><font size="2">www.hi-jena.de</font></a><br>
<br>
GSI Helmholtzzentrum für Schwerionenforschung<br>
Planckstrasse 1<br>
64291 Darmstadt<br>
Germany<br>
</span></font><a href="http://www.gsi.de" id="LPNoLP"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt"><font size="2">www.gsi.de</font></span></font></a></div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Weber, Guenter Dr. <g.weber@hi-jena.gsi.de><br>
<b>Gesendet:</b> Mittwoch, 21. Februar 2024 16:14:45<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] Report of a possible bug of the CAEN_V560 module</font>
<div> </div>
</div>
<div>
<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></div>
</body>
</html>