Yes, there is some systematic board noise on this prototype, unfortunately 

Ok, then it seems the other post I made might still belong in this thread after all.

Thanks for confirming negative spike behavior, we now have a mitigation plan going forward.

Cheers,

Hello,

I had forgotten to disable the turn off the power to the USB drive on Windows and DRS4 stopped triggering. Now, we are all on quarantine and I am unable to reset the board to normal function. Are there any commands to reset the board remotely. I tried all of the default Windows based solutions such as disable USB port etc., but I am unable to do this. Only thing that has worked in the past is manually replugging the USB but I do not have the option to do that currently. Please help.

Thanks,

Ajay 

Hello the DRS4 team,

I and some of my colleagues are using DRS4 evaluation boards (ver. 3) for the R&D of the Cherenkov Telescope Array project. During 
our PMT measurements, we have encountered a problem which is probably related to USB connection. In fact, I cannot reproduce this 
problem with my Linux virtual machine (Scientific Linux 5 64 bit), but other colleagues from three different universities in Japan 
reported the same problem with their real machines.

=== Short Summary ===
DRSBoard::SetFrequency occasionally stops

=== Environment ===
- drs-3.0.0
- Scientific Linux 5.5 (32 bit)
- lib-usb-devel-0.1.12-5.1.i386

=== Steps to Reproduce the Problem ===
1. Compile the attached file drs_simple.cpp with drs-3.0.0
2. Repeat the following command several times from a terminal

$ drs_simple -0.05 1000 ./outputfilename.dat true 2.

3. The above command may stop. In that case, you need to kill the command by Ctrl-C.

=== Comments ===
- Once the command stops, we cannot run the above command properly.
- If we unplug and plug the USB cable again, the command can be executed again.
- It seems that the program stops inside DRSBoard::SetFrequency

I would very appreciate it if you could give me any advise. If you need further information, please let me know.

Akira

Hi,

although I don't have a chance to test your code, it looks very similar to what I am using.

I can confirm that the DRS4 communication breaks down if the program talking to the DRS4 is closed abruptly or before is has a chance 
to properly execute "delete drs" where it closes the USB connection.

For me if I terminate the program that's using DRS4, the next time I might or might not be able to connect to the DRS4 because I would 
get a magic number or the program would just stop. The DRS4 eval board needs to be restarted via pulling the plug if the orange LED is 
not ON.

I have tried to power down the DRS4 board via software under SL6 linux, but the reality is that the DRS4 eval board is powered directly 
by the 5V USB rail off the computer, and you cannot software control that, you can only suspend the communication of the USB 
port/device.

So I don't have a solution to fix this issue, but my best advice is to change your software such that it calls "delete drs" to 
terminate the USB connection before you close or terminate the program.

Oh and I have not tried running multiple programs at the same time to see if that might be causing the issue as well. The usb library 
might simply error out saying the device is inaccessible because it's being used.

> Hello the DRS4 team,
> 
> I and some of my colleagues are using DRS4 evaluation boards (ver. 3) for the R&D of the Cherenkov Telescope Array project. During 
> our PMT measurements, we have encountered a problem which is probably related to USB connection. In fact, I cannot reproduce this 
> problem with my Linux virtual machine (Scientific Linux 5 64 bit), but other colleagues from three different universities in Japan 
> reported the same problem with their real machines.
> 
> === Short Summary ===
> DRSBoard::SetFrequency occasionally stops
> 
> === Environment ===
> - drs-3.0.0
> - Scientific Linux 5.5 (32 bit)
> - lib-usb-devel-0.1.12-5.1.i386
> 
> === Steps to Reproduce the Problem ===
> 1. Compile the attached file drs_simple.cpp with drs-3.0.0
> 2. Repeat the following command several times from a terminal
> 
> $ drs_simple -0.05 1000 ./outputfilename.dat true 2.
> 
> 3. The above command may stop. In that case, you need to kill the command by Ctrl-C.
> 
> === Comments ===
> - Once the command stops, we cannot run the above command properly.
> - If we unplug and plug the USB cable again, the command can be executed again.
> - It seems that the program stops inside DRSBoard::SetFrequency
> 
> I would very appreciate it if you could give me any advise. If you need further information, please let me know.
> 
> Akira

Hello Andrey,

Thank you for your advise. But we never terminated the program before closing and deleting the DRS object. What we did was just executing the program multiple times 
repeatedly.

Akira

Hi,

finally I found some time to look into this problem, sorry for the late delay.

I tried your program and started it maybe 50 times without an issue. So I cannot reproduce your problem.

I know that if you do Ctrl-C then you might have some data "stuck" in the USB interface, like you ask for a 
waveform data buffer but you never read it because you got interrupted by the Ctrl-C. But when you reinitialize 
the board the next time, all stuck data is drained before the board is initialized. This is done in DRS.cpp 
around line 343:

            /* drain any data from Cy7C68013 FIFO if FPGA startup caused erratic write */
            do {
               i = musb_read(usb_interface, 8, buffer, sizeof(buffer), 100);
               if (i > 0)
                  printf("%d bytes stuck in buffer\n", i);
            } while (i > 0);


So occasionally, after a restart after a Ctrl-C, you will see "xxx bytes stuck in buffer", but then the boards 
should come up correctly.

If you have the problem without Ctrl-C, then maybe your specific board has a hardware problem? Do you have 
access to another board? 

Best regards,
Stefan

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

 Then why don't you use the .iic file and forget about the hex and c files? Honestly speaking, I don't remember what source file I compiled a couple of years ago, and it could be that an older file slipped into the repository, but that's all I have. I would have to investigate myself, try to compile and program the c file, do the debugging, and find out what the differences are. But unfortunately I don't have time for that right now. So just stick with the .iic file.

Thanks for the help.

I'm not doing this for fun, checking that the source matches the .iic ! I know I could directly use the .iic and forget about the hex and c files.

I just wanted to use your source file as the starting point for my own board, as everybody is doing at the application level.

Hi,

I've failured to compile official software. The cause is the following line.

DOFrame.h L.111    bool GetRefclk()        { return m_refClk > 0; }

m_refClk is pointer to bool. I guess these line is for null-check of the pointer.

Can I replace the following line as 

bool GetRefclk()        { return m_refClk != nullptr; }

?

The latest compilers may not accept C-style check.

My compiler version is

Apple clang version 11.0.3 (clang-1103.0.32.59)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Best regards,

Keita

The software is a bit outdated, I will soon make a new release. 

In meantime, you can replace that like with

bool GetRefclk(int board) { return m_refClk[board]; }

Best,
Stefan 

Hello,

I am working on a custom PCB design with the DRS4 chip, and I can't get the PLL to lock.  I'm feeding CLKIN with a 1MHz CMOS clock (REFCLK- tied to VDD/2), and I'm using the same loop filter as the eval board.  I see from the datasheet that the PLL is enabled by default, so I'm not writing anything to the config register on startup.  I am just driving DENABLE high approx. 100ms after startup and looking for the PLL lock bit to go high.  When I look at DTAP, I see a 3MHz signal.  Can anyone tell me what I'm doing wrong?

-Tom

I guess you mean "1 MHz clock at REFCLK+", and not CLKIN, there is no CLKIN, just a SRCLK, but that is someting else!

There could be many reasons why this is not working. It's hard for me to debug your board without actually having it in hands. So just some ideas:

- Supply a clean differential REFCLK, I never tried one end tied to VDD/2

- Is /RESET high?

- Is BIAS at roughly 0.7V?

- Is A0-A3 different from 1111, which puts the chip in standby

- Did you double check your loop filter?

The easiest usually is to start from a running evaluation board, then compare all pins 1:1 with your board.

Stefan

Stefan,

Thanks for responding so quickly.  Yes I have my clock source going to REFCLK+ (CLKIN is the signal name on my schematic).  BIAS is 0.7V exactly, /RESET is high, A0-A3 are 0x0000, and the loop filter has a 4.7nF cap to GND with a 130ohm resistor + 1uF cap in parallel, just like the eval board.

Regarding the clock - I am not using an LVDS clock, but rather a 2.5V-level clock signal, with REFCLK- tied to 1.25V.  Sheet 9 of the datasheet states:  If no LVDS reference clock signal is available, a CMOS signal can be connected to REFCLK+ and the REFCLK input is connected to VDD/2 via a resistor divider.

Is that not a true statement?

-Tom