DRS4 Forum
  DRS4 Discussion Forum, Page 11 of 40  Not logged in ELOG logo
ID Date Author Subjectup
  307   Tue Nov 19 04:33:22 2013 Andriy ZatserklyaniyDRSOsc at Mac OS X Mavericks

 I installed Mac OS package on macbook (late 2013). DRSOsc starts to write file but freezes; need to be restarted to restore connection with DRS4 evaluation board (ordered Aug 2011). 

When I ran from the command line, I see these messages:

phone$ /Applications/DRSOsc.app/Contents/MacOS/DRSOsc

2013-11-18 15:11:31.278 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-18 15:11:31.279 DRSOsc[96539:507] CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.

2013-11-18 15:11:31.281 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-18 15:11:31.283 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-18 15:11:31.285 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

0 - 0.250

1 - 0.250

2 - 0.250

3 - 0.250

0 - 0.250

1 - 0.250

2 - 0.250

3 - 0.250

2013-11-18 15:11:32.933 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

...

...

 

and these:

 

musb_write: requested 10, wrote 0, errno -4 (Unknown error: -4)

musb_read error 0

musb_write: requested 10, wrote 0, errno -4 (Unknown error: -4)

musb_read error 0

...

...

 

I tried to compile Linux package, but got error messages:

 

drs-4.0.1$ make

cc -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/opt/local/include -DOS_DARWIN -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -c src/musbstd.c

cc -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/opt/local/include -DOS_DARWIN -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -c src/mxml.c

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: expected parameter declarator

size_t EXPRT strlcpy(char *dst, const char *src, size_t size);

             ^

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: expected ')'

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

include/strlcpy.h:27:14: note: to match this '('

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                    ^

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]

size_t EXPRT strlcpy(char *dst, const char *src, size_t size);

             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                              ^~~~~~~~~~~~~~~~~~~~~

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: conflicting types for '__builtin___strlcpy_chk'

/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

  ^

include/strlcpy.h:27:14: note: '__builtin___strlcpy_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'

/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

  ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: expected parameter declarator

size_t EXPRT strlcat(char *dst, const char *src, size_t size);

             ^

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: expected ')'

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

include/strlcpy.h:28:14: note: to match this '('

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                    ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]

size_t EXPRT strlcat(char *dst, const char *src, size_t size);

             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                              ^~~~~~~~~~~~~~~~~~~~~

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: conflicting types for '__builtin___strlcat_chk'

/usr/include/secure/_string.h:111:3: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

  ^

include/strlcpy.h:28:14: note: '__builtin___strlcat_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'

/usr/include/secure/_string.h:111:3: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

  ^

2 warnings and 6 errors generated.

make: *** [mxml.o] Error 1

 

 

What the best way to build DRSOsc on the Mac OS X?

 

Thanks,

Andriy.

  308   Tue Nov 19 09:09:01 2013 Stefan RittDRSOsc at Mac OS X Mavericks

Andriy Zatserklyaniy wrote:

I installed Mac OS package on macbook (late 2013). DRSOsc starts to write file but freezes; need to be restarted to restore connection with DRS4 evaluation board (ordered Aug 2011). 

DRSOsc seems broken on OSX 10.9. I'm working on this right now. Some of the problems are related to wxWidgets, so I'm waiting for a new version running stably under OSX 10.9. The compilation problem related to "strlcpy" comes from the fact that OSX 10.9 now comes with its own version of that function, while all previous versions did not. So simply removing strlcpy.h/c from the project fixes that.

There will be a new version of DRSOsc next month which fixes all this problems, so just stay tuned.

/Stefan 

  309   Tue Nov 19 21:49:37 2013 Andriy ZatserklyaniyDRSOsc at Mac OS X Mavericks

Stefan Ritt wrote:

Andriy Zatserklyaniy wrote:

I installed Mac OS package on macbook (late 2013). DRSOsc starts to write file but freezes; need to be restarted to restore connection with DRS4 evaluation board (ordered Aug 2011). 

DRSOsc seems broken on OSX 10.9. I'm working on this right now. Some of the problems are related to wxWidgets, so I'm waiting for a new version running stably under OSX 10.9. The compilation problem related to "strlcpy" comes from the fact that OSX 10.9 now comes with its own version of that function, while all previous versions did not. So simply removing strlcpy.h/c from the project fixes that.

There will be a new version of DRSOsc next month which fixes all this problems, so just stay tuned.

/Stefan 

 I will have beam test next week :-(

I installed wxWidgets-3.0 using MacPorts (and libusb too). After removing strlcpy and hacking of Makefile I managed to build MacOS application. 

 

When I launch DRSOsc.app/Contents/MacOS/DRSOsc from terminal, I see constantly pouring messages about fonts:

2013-11-19 12:21:22.232 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-19 12:21:22.275 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

...

How may I get rid of them?

 

Another problem: I was not able to save data in binary (*.dat) file. I used DRSOsc settings to set binary format, I specified explicit extension *.dat, tried everything (including hiding extension), but was not able to save in binary format. Do I need to apply some trick? How may I hardcode usage of the binary format?

Thanks,

Andriy.

  310   Wed Nov 20 08:16:10 2013 Stefan RittDRSOsc at Mac OS X Mavericks

Andriy Zatserklyaniy wrote:

When I launch DRSOsc.app/Contents/MacOS/DRSOsc from terminal, I see constantly pouring messages about fonts:

2013-11-19 12:21:22.232 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-19 12:21:22.275 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

Another problem: I was not able to save data in binary (*.dat) file. I used DRSOsc settings to set binary format, I specified explicit extension *.dat, tried everything (including hiding extension), but was not able to save in binary format. Do I need to apply some trick? How may I hardcode usage of the binary format?

The CoreText issue comes from WxWidgets or a combination with OSX 10.9. Many other people have the same problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=934261

and I have no idea how to get rid of it.

Concerning your problem with the binary format, just have a look at elog:272

 

  14   Wed Oct 14 23:53:05 2009 Armin KolbDRS_exam using USB Evaluation Board with OS X

For the users using a Macintosh,

after several hours the Evaluation Board is working  on my Macintosh (intel).

1) install the development package with xcode, its on the OS X installation DVD

2) install the libusb binary from http://www.ellert.se/twain-sane/

3) modify the makefile  for compiling drs_exam (attached) afterwards it's running perfect!

 

best,

Armin

 

Attachment 1: Makefile
########################################################
#
#  Makefile for drs_exam executables
#  under OS X Macintosh with Bash Shell
#
#
########################################################

CFLAGS        = -g -O2 -Wall -Iinclude -DOS_LINUX -DHAVE_LIBUSB
LIBS          = -lpthread -lutil -lusb

CPP_OBJ       = DRS.o
OBJECTS       = musbstd.o mxml.o strlcpy.o

all: drs_exam

drs_exam: $(OBJECTS) DRS.o drs_exam.o
	$(CXX) $(CFLAGS) $(OBJECTS) DRS.o drs_exam.o -o drs_exam $(LIBS)

drs_exam.o: src/drs_exam.cpp include/mxml.h include/DRS.h
	$(CXX) $(CFLAGS) -c $<

$(CPP_OBJ): %.o: src/%.cpp include/%.h include/mxml.h include/DRS.h
	$(CXX) $(CFLAGS) $(WXFLAGS) -c $<

$(OBJECTS): %.o: src/%.c include/mxml.h include/DRS.h
	$(CXX) $(CFLAGS) -c $<

clean:
	rm -f *.o drscl drsosc

  15   Fri Oct 16 09:51:03 2009 Jinhong WangDSR4 Full Readout Mode

Hello Mr. Stefan Ritt

          In DSR4 DATASHEET Rev.0.8 Page13, I noticed you metioned the samping should occur after 38 ns after the rising edge of SRCLK when the multiplexer is used. So what is suggested value(delay time between sampling and the rising edge of SRCLK) for the parallel mode,in which the multiplexer is not used?

          Best wishes!

                                                       Jinhong Wang

  16   Fri Oct 16 10:16:10 2009 Stefan RittDSR4 Full Readout Mode

Jinhong Wang wrote:

Hello Mr. Stefan Ritt

          In DSR4 DATASHEET Rev.0.8 Page13, I noticed you metioned the samping should occur after 38 ns after the rising edge of SRCLK when the multiplexer is used. So what is suggested value(delay time between sampling and the rising edge of SRCLK) for the parallel mode,in which the multiplexer is not used?

          Best wishes!

                                                       Jinhong Wang

The clock-to-output delay is the same if one uses the multiplexer or not. I found however that in most cases the delay of 38 ns needs some fine tuning to get optimal performance. So I typically use a shifted clock generated by the FPGA clock manager with a programmable delay (+-5 ns for Xilinx) and optimize this in the running system.

  80   Thu May 13 19:14:27 2010 Hao HuanDVDD Problem of DRS 4

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

  81   Fri May 14 08:40:14 2010 Stefan RittDVDD Problem of DRS 4

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

  82   Tue May 18 01:47:59 2010 Hao HuanDVDD Problem of DRS 4

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

  83   Tue May 18 08:23:07 2010 Stefan RittDVDD Problem of DRS 4

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

  85   Wed May 19 02:24:12 2010 Hao HuanDVDD Problem of DRS 4

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

 Yes; I used RSRLOAD to trigger readout of all channels in parallel so the asymmetry between channels of the same chip is really a big puzzle. Also during reset DSPEED indeed goes to 2.5V, but after reset the PLL will not try to lock with the external reference clock and lower DSPEED. Instead the Domino circuit just oscillates at the highest frequency by itself.

A more confusing discovery is that the SRIN level before starting the Domino wave could affect the behavior of the PLL. I mean the level of SRIN when the chip is at A="1111" or "1010". Is SRIN supposed to influence the chip even in these standby or transparent modes?

  86   Wed May 19 09:16:02 2010 Stefan RittDVDD Problem of DRS 4

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

 Yes; I used RSRLOAD to trigger readout of all channels in parallel so the asymmetry between channels of the same chip is really a big puzzle. Also during reset DSPEED indeed goes to 2.5V, but after reset the PLL will not try to lock with the external reference clock and lower DSPEED. Instead the Domino circuit just oscillates at the highest frequency by itself.

A more confusing discovery is that the SRIN level before starting the Domino wave could affect the behavior of the PLL. I mean the level of SRIN when the chip is at A="1111" or "1010". Is SRIN supposed to influence the chip even in these standby or transparent modes?

Just some ideas:

  • Is DENABLE really kept high all the time?
  • Is DRESET only applied once during initialization, after that it should stay high
  • Does  REFCLK+/REFCLK- really toggle at the required sampling speed / 2048?
  • Is the REFCLK really a good differential signal? Note that it must be biased properly since the DRS4 inputs are high impedance
  • Is the Bit1 in the Config Register really at "1" to enable the PLL?

The only way the SRIN level could affect the PLL is if you address the Config Register (A="1100") and you clock in a few bits with SRCLK.

Have you thought about 'crazy' things such as:

  • Defining the DRS4 chip wronly in your CAD software so that the pins are different from what you think?
  • Some soldering problem of the DRS4 chips (we had this in the past) so that some pins are not connected at all and others have shorts

I guess you checked most of the things, so I'm just wildly guessing in order to stimulate some thoughts.

The ultimate check would be to get one of the evaluation boards (I sent a few to Jean-Francois Genat some time ago...) and compare the DRS4 signals pin by pin.

  91   Fri Jun 18 11:31:20 2010 Jinhong WangDVDD Problem of DRS 4

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

 Yes; I used RSRLOAD to trigger readout of all channels in parallel so the asymmetry between channels of the same chip is really a big puzzle. Also during reset DSPEED indeed goes to 2.5V, but after reset the PLL will not try to lock with the external reference clock and lower DSPEED. Instead the Domino circuit just oscillates at the highest frequency by itself.

A more confusing discovery is that the SRIN level before starting the Domino wave could affect the behavior of the PLL. I mean the level of SRIN when the chip is at A="1111" or "1010". Is SRIN supposed to influence the chip even in these standby or transparent modes?

Just some ideas:

  • Is DENABLE really kept high all the time?
  • Is DRESET only applied once during initialization, after that it should stay high
  • Does  REFCLK+/REFCLK- really toggle at the required sampling speed / 2048?
  • Is the REFCLK really a good differential signal? Note that it must be biased properly since the DRS4 inputs are high impedance
  • Is the Bit1 in the Config Register really at "1" to enable the PLL?

The only way the SRIN level could affect the PLL is if you address the Config Register (A="1100") and you clock in a few bits with SRCLK.

Have you thought about 'crazy' things such as:

  • Defining the DRS4 chip wronly in your CAD software so that the pins are different from what you think?
  • Some soldering problem of the DRS4 chips (we had this in the past) so that some pins are not connected at all and others have shorts

I guess you checked most of the things, so I'm just wildly guessing in order to stimulate some thoughts.

The ultimate check would be to get one of the evaluation boards (I sent a few to Jean-Francois Genat some time ago...) and compare the DRS4 signals pin by pin.

 Hi Stefan

       I designed the evaluation board for our experiment. On our boards, I  encountered the similar problem when working on the PLL of DRS4. I compared the following two configuration process, which on with PLL locked, the other not,

   Process1: 

       step 1: Set DEnable and DWrite low, 

      Step2 : Reset DRS4 with a negative pulse of about 900 ns

      Step3: Set DEnable high,  thus do nothing but wait

       I found DRS4 PLL working and locked. 

  

  Process 2:

   Step 1: Set DEnable and DWrite low, 

  Step2 : Reset DRS4 with a negative pulse of about 900 ns 

  Step3: Set Config. Register( "11111111" .of course, this step was not necessary, just to see whether SPI was working properly from DTAP when set to "11111110")

  Step4: Set The read shift Register ( full read out mode)

  Step5: Set DEnable high, 

  Step6: Set DWrite high  , thus low it , and prepare to read the waveform.

  Well, I found in this case, the PLL was not locked, I am sure there was no problem with my SPI configuration process of DRS4. 

  toggle from DTAP could be viewed, but not stable. 

 Any Suggestions ?

  thanks.

  92   Fri Jun 18 11:45:18 2010 Stefan RittDVDD Problem of DRS 4

Jinhong Wang wrote:

 

 Hi Stefan

       I designed the evaluation board for our experiment. On our boards, I  encountered the similar problem when working on the PLL of DRS4. I compared the following two configuration process, which on with PLL locked, the other not,

   Process1: 

       step 1: Set DEnable and DWrite low, 

      Step2 : Reset DRS4 with a negative pulse of about 900 ns

      Step3: Set DEnable high,  thus do nothing but wait

       I found DRS4 PLL working and locked. 

  

  Process 2:

   Step 1: Set DEnable and DWrite low, 

  Step2 : Reset DRS4 with a negative pulse of about 900 ns 

  Step3: Set Config. Register( "11111111" .of course, this step was not necessary, just to see whether SPI was working properly from DTAP when set to "11111110")

  Step4: Set The read shift Register ( full read out mode)

  Step5: Set DEnable high, 

  Step6: Set DWrite high  , thus low it , and prepare to read the waveform.

  Well, I found in this case, the PLL was not locked, I am sure there was no problem with my SPI configuration process of DRS4. 

  toggle from DTAP could be viewed, but not stable. 

 Any Suggestions ?

  thanks.

So the main difference, if I understand correctly, is the setting of the Config Register. Actually I never tried that, I always went with the default settings (all "1"). What happens if you write "00000000"? You know Bit1 controls the PLL, maybe there is a bug and the signal needs to be inverted. 

  93   Sat Jun 19 10:09:18 2010 Jinhong WangDVDD Problem of DRS 4

Stefan Ritt wrote:

Jinhong Wang wrote:

 

 Hi Stefan

       I designed the evaluation board for our experiment. On our boards, I  encountered the similar problem when working on the PLL of DRS4. I compared the following two configuration process, which on with PLL locked, the other not,

   Process1: 

       step 1: Set DEnable and DWrite low, 

      Step2 : Reset DRS4 with a negative pulse of about 900 ns

      Step3: Set DEnable high,  thus do nothing but wait

       I found DRS4 PLL working and locked. 

  

  Process 2:

   Step 1: Set DEnable and DWrite low, 

  Step2 : Reset DRS4 with a negative pulse of about 900 ns 

  Step3: Set Config. Register( "11111111" .of course, this step was not necessary, just to see whether SPI was working properly from DTAP when set to "11111110")

  Step4: Set The read shift Register ( full read out mode)

  Step5: Set DEnable high, 

  Step6: Set DWrite high  , thus low it , and prepare to read the waveform.

  Well, I found in this case, the PLL was not locked, I am sure there was no problem with my SPI configuration process of DRS4. 

  toggle from DTAP could be viewed, but not stable. 

 Any Suggestions ?

  thanks.

So the main difference, if I understand correctly, is the setting of the Config Register. Actually I never tried that, I always went with the default settings (all "1"). What happens if you write "00000000"? You know Bit1 controls the PLL, maybe there is a bug and the signal needs to be inverted. 

 Hi, Stefan,

       The problem was fixed by setting Reg_addr "1001" instead of "1111" when in idle state, I was confused. 

  228   Mon Mar 25 11:12:53 2013 Georg WinnerDifferences in Source Code

I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.

drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.

drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":

There is no operation which  calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?

 

  230   Thu Apr 4 11:21:04 2013 Stefan RittDifferences in Source Code

Georg Winner wrote:

I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.

drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.

drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":

There is no operation which  calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?

 

Thanks for reporting the problem in drs_exam.cpp. The windows and linux versions sometimes differ a bit. I'm working right now on a complete new version, wich will bring both together again.

Concerning fTriggerDelayNs and ticks, they are correlated. One tick is a single delay unit in the FPGA. On the newest boards the unit is 4.8ns long. So

ticks = fTriggerDelayNs / 4.8

fTriggerDelayNs = ticks * 4.8

fTriggerDelayNs gets set at the first line of SetTriggerDelayNs:

int DRSBoard::SetTriggerDelayNs(int delay)
/* set trigger delay in nanoseconds */
{
   short ticks, reg;
   fTriggerDelayNs = delay;

So I cannot see how fTriggerDelayNS should get diverse values?

 

  733   Mon Feb 4 16:42:08 2019 Hans SteigerDifferent Distances between the sampling points

Dear All,

with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s). 

How can i fix this?

Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format.  Which version would be old enough?

 

All the best and thanks a lot,

 

Hans

  734   Mon Feb 4 16:46:04 2019 Stefan RittDifferent Distances between the sampling points

The sampling points are NOT equidestant, they have varying bin widths of 150ps to 250ps at 5GS/s. That's due the way the DRS4 chip works. You might have neglected that fact in the past, but that would have led to poor timing resolutions (typically 1-2ns resolution only). To get bins with the same width, you have to treat your waveform as a real X/Y points (or better U/T), and the re-sample that cure, maybe spline-interpolated, at 200ps bins.

Stefan

Hans Steiger wrote:

Dear All,

with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s). 

How can i fix this?

Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format.  Which version would be old enough?

 

All the best and thanks a lot,

 

Hans

 

ELOG V3.1.4-80633ba