ID |
Date |
Author |
Subject |
826
|
Fri Apr 9 21:56:54 2021 |
Sean Quinn | Unexpected noise in muxout: t_samp related? | 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,
Stefan Ritt wrote: |
If you do the cell calibration correctly, your noise should be ~0.4 mV. You seem to be 2-3x larger. The periodic negative spikes come if you dont' sample at the right time. Adjust t_samp until they are gone.
Stefan
Sean Quinn wrote: |
Hi Stefan,
Thanks much for the quick reply. Ok, yes, things do seem ok after the offset calibration. I am running into some other issues I could use your advice on but will make a separate thread. As a preview, you can see hints in this waveform (periodic negative spikes).
This one should be considered resolved.
Stefan Ritt wrote: |
Dear Sean,
noise in transparent mode comes from some coupling to your system clock. But 3.5 mV RMS seems rather hight to me. You should get it to below 1 mV if the DRS4 input is clean (try to short it).
The noise in the readout is expected. It looks exactly as Plot3 from the data sheet. You have to calibrate it away with a fixed offset for each cell as described in this paper: https://arxiv.org/abs/1405.4975 (paragraph IV. A. Voltage Calibration).
Concerning t_samp: Fig 11 in the datasheet just tells you that the rising edge of the SRCLK should come later than t_s after the address change. t_s is the setup time and 5 ns. Fig 12 tells you that the ADC should sample the analog output of the DRS t_samp after the address change A0-A3 and t_samp after the rising edge of SRCLK.
The digitizing speed of the evaluation board is indeed 15 MHz instead of the maximum 30 MHz, because this was easier to program in the FPGA. The t_samp has to be there so that the analog output signal of the DRS4 settles to its final value after each SRCLK pulse. If you sample "too early", you sample with the ADC the output when it is sill moving. So you have to wait until the analog is settled, but just before the next DRS sample becomes visible at the output. You can fine tune this with a differential probe at the DRS4 analog output (on a single ended probe you might drown in noise) on one channel of yoru scope and the ADC sample clock on the other channel of your scope. Note that the ADC sample clock cannot be derived straight from your FPGA clock, but you need some clock manager to fine-adjust its phase in 1ns steps.
But again, looking at your output, everything seems fine. You see the 5mV rms noise indicated in the datasheet table 1, which translates to about 20 mV peak-to-peak. If you do the offset calibration, this should go down to below 1 mV.
Best,
Stefan
Sean Quinn wrote: |
Dear DRS4 team,
I'm experiencing some issues that seem to be isolated to the ASIC, and would like to understand if we are doing something wrong. There are several items to address in the post.
First, I do not think the noise observed is being injected from elsewhere on the board. If I run the DRS in transparent mode, the baseline noise is low, on order 3.5 mV (60 ADU), perhaps radiated from a clock. See below image. The scale is 0 to 1000 ADU with LSB = 6 uV (same AD9245 as eval board.). The DRS is in RUNNING state, I have forced a trigger in the ILA. This is for a single channel, CH0, 1024 cells.
In the next image, I show the waveform obtained from a full readout. This corresponds to ADC_READOUT state, and the plot uses the same 1000 ADU scale. Noise seems around 350 ADU now, many factors worse than before.
We've spent a lot of time trying to understand what's happening. One area that would be helpful to get some guidance on is the "t_samp" parameter. In Fig. 11 of the data sheet, should there be a t_samp label between t_s and t_clk? It just has arrows there with some width.
In our current firmware I believe R1 is simply one clock after R0 (for both ROI and full readout mode). Would this lead to the added noise observed in muxout?
This leads to the next question on what to actually use for t_samp. In the data sheet, page 4 "Timing Characteristics" it says to use t_samp = t0 + t_clk. Additionally, t0= 10 ns from that table. Fair enough.
But if I check this against the eval board timing, I see very different values. Here the clock is 15 MHz so t_clk=67 ns (I note another post about this topic https://elog.psi.ch/elogs/DRS4+Forum/713), so I expect t_samp = 77 ns. But in practice it looks like the R0 to R1 delay is ~465 ns? (cyan=RSRLOAD, yellow=SRCLK)
Given this, is t_samp a value that should be tuned by the user?
Best regards,
Sean
|
|
|
|
|
783
|
Mon Mar 23 15:03:28 2020 |
Ajay Krishnamurthy | USB trigger issue | 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 |
292
|
Tue Sep 10 10:31:30 2013 |
Akira Okumura | USB connection stops | 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 |
Attachment 1: drs_simple.cpp
|
/********************************************************************\
Name: drs_simple.cpp
Modified : Hide Katagiri
Originally created by: Stefan Ritt
Contents: Simple example application to read out a DRS4
evaluation board
$Id: drs_exam.cpp 13344 2009-04-28 07:34:45Z ritt@PSI.CH $
\********************************************************************/
#include <math.h>
#ifdef _MSC_VER
#include <windows.h>
#elif defined(OS_LINUX)
#define O_BINARY 0
#include <unistd.h>
#include <ctype.h>
#include <sys/ioctl.h>
#include <errno.h>
#define DIR_SEPARATOR '/'
#endif
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "strlcpy.h"
#include "DRS.h"
#include <fstream>
#include <iostream.h>//20130814 add tanaka
/*------------------------------------------------------------------*/
//std::cerr << "debug output 1" << std::endl;
int main(int argc, char *argv[])
{
int i, j, nBoards;
DRS *drs;
DRSBoard *b;
float time_array[1024];
float wave_array[1][1024];// old ver. [8][1024]
std::cerr << "debug output 2" << std::endl;
//// arguments, inirialization
//
float threshold=0.1;
if (argc > 1) {
threshold=atof(argv[1]); // in volt
};
//
std::cerr << "debug output 3" << std::endl;
int nevent=10;
if (argc > 2) {
nevent=atoi(argv[2]);
};
//
std::cerr << "debug output 4" << std::endl;
char *fname="tmp.dat";
if (argc > 3) {
fname=argv[3];
};
//
std::cerr << "debug output 5" << std::endl;
bool negative_edge=false; // true is negative
if (argc > 3) {
if (argv[4]=="true") {
negative_edge=true;
};
};
//
std::cerr << "debug output 6" << std::endl;
float freq=2.; // sampling frequency (GHz)
if (argc > 4) {
freq=atof(argv[5]);
};
std::cerr << "debug output 7" << std::endl;
std::ofstream fout;
fout.open(fname); // attention! file is truncated if the file fname already exists.
if (!fout.is_open()) {
exit(1);
}
std::cerr << "debug output 8" << std::endl;
/* do initial scan */
drs = new DRS();
std::cerr << "debug output 9" << std::endl;
/* show any found board(s) */
for (i=0 ; i<drs->GetNumberOfBoards() ; i++) {
b = drs->GetBoard(i);
printf("Found DRS4 evaluation board, serial #%d, firmware revision %d\n",
b->GetBoardSerialNumber(), b->GetFirmwareVersion());
}
std::cerr << "debug output 10" << std::endl;
/* exit if no board found */
nBoards = drs->GetNumberOfBoards();
if (nBoards == 0) {
printf("No DRS4 evaluation board found\n");
return 0;
}
std::cerr << "debug output 11" << std::endl;
/* continue working with first board only */
b = drs->GetBoard(0);
std::cerr << "debug output 12" << std::endl;
/* initialize board */
b->Init();
std::cerr << "debug output 13" << std::endl;
/* set sampling frequency */
b->SetFrequency(freq, true);
std::cerr << "debug output 14" << std::endl;
/* enable transparent mode needed for analog trigger */
b->SetTranspMode(1);
std::cerr << "debug output 15" << std::endl;
/* use following line to disable hardware trigger */
//b->EnableTrigger(0, 0);
/* use following line to enable external hardware trigger (Lemo) */
b->EnableTrigger(1, 0);
std::cerr << "debug output 16" << std::endl;
/* set input range to -0.5V ... +0.5V */
// b->SetInputRange(0);
b->SetInputRange(0.45); //does not work?
std::cerr << "debug output 17" << std::endl;
/* use following lines to enable hardware trigger on CH1 at 250 mV positive edge */
// b->EnableTrigger(0, 1); // lemo off, analog trigger on
// b->SetTriggerSource(0); // use CH1 as source
// b->SetTriggerLevel(0.25, false, 0); // 0.25 V, positive edge, zero delay
// b->SetTriggerLevel(threshold, negative_edge); // -0.05 V, negative edge
b->SetTriggerDelay(120); // zero trigger delay, this places pulse in
std::cerr << "debug output 18" << std::endl;
/* repeat nevent times */
for (j=0 ; j<nevent ; j++) {
/* start board (activate domino wave) */
b->StartDomino();
//std::cerr << "debug output 19" << std::endl;
/* wait for trigger */
//fout << "% Start to read Event #" << j << std::endl;
while (b->IsBusy());
//std::cerr << "debug output 20" << std::endl;
/* read all waveforms */
b->TransferWaves(0, 8);
//std::cerr << "debug output 21" << std::endl;
/* read time (X) array in ns */
b->GetTime(0, time_array);
//std::cerr << "debug output 22" << std::endl;
/* decode waveform (Y) array first channel in mV */
b->GetWave(0, 0, wave_array[0]);
/* decode waveform (Y) array second channel in mV*/
// b->GetWave(0, 1, wave_array[1]);
/* process waveform: add here some code to display or save waveform X=time[i], Y=wave_array[n][i] */
//std::cerr << "debug output 23" << std::endl;
for (i=0;i<1024;i++) {
fout << time_array[i] << " " << wave_array[0][i] << std::endl;
}
//std::cerr << "debug output 24" << std::endl;
/* print some progress indication */
//fout << "% Event #" << j << " read successfully" << std::endl;
//std::cerr << "debug output 25" << std::endl;
}
//std::cerr << "debug output 26" << std::endl;
fout.close();
//std::cerr << "debug output 27" << std::endl;
/* delete DRS object -> close USB connection */
delete drs;
//std::cerr << "debug output 28" << std::endl;
}
|
293
|
Wed Sep 11 02:41:28 2013 |
Andrey Kuznetsov | USB connection stops | 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 |
297
|
Wed Sep 25 14:42:00 2013 |
Akira Okumura | USB connection stops | 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 |
324
|
Wed Jan 15 15:48:55 2014 |
Stefan Ritt | USB connection stops | 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 |
377
|
Tue Oct 7 14:09:02 2014 |
Stephane Debieux | USB Microcontroller firmware | 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
|
378
|
Mon Oct 13 16:46:56 2014 |
Stefan Ritt | USB Microcontroller firmware |
Stephane Debieux wrote: |
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 |
379
|
Mon Oct 13 17:08:40 2014 |
Stephane Debieux | USB Microcontroller firmware |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
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 |
380
|
Mon Oct 13 17:14:58 2014 |
Stefan Ritt | USB Microcontroller firmware |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
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 |
381
|
Tue Oct 14 16:21:07 2014 |
Stephane Debieux | USB Microcontroller firmware |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
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. |
382
|
Tue Oct 14 16:29:12 2014 |
Stefan Ritt | USB Microcontroller firmware |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
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? |
383
|
Tue Oct 14 16:34:45 2014 |
Stephane Debieux | USB Microcontroller firmware |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
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. |
384
|
Tue Oct 14 16:38:14 2014 |
Stefan Ritt | USB Microcontroller firmware |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
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. |
385
|
Tue Oct 14 16:51:37 2014 |
Stephane Debieux | USB Microcontroller firmware |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
Stefan Ritt wrote: |
Stephane Debieux wrote: |
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. |
785
|
Thu May 21 07:38:05 2020 |
Keita Mizukoshi | Type check at DOFrame.h in official software | 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 |
788
|
Fri May 22 13:24:51 2020 |
Stefan Ritt | Type check at DOFrame.h in official software | 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
Keita Mizukoshi wrote: |
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
|
|
811
|
Fri Feb 26 17:05:26 2021 |
Tom Schneider | Trouble getting PLL to lock | 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 |
812
|
Fri Feb 26 17:59:14 2021 |
Stefan Ritt | Trouble getting PLL to lock | 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
Tom Schneider wrote: |
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
|
|
813
|
Fri Feb 26 18:33:52 2021 |
Tom Schneider | Trouble getting PLL to lock | 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
Stefan Ritt wrote: |
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
Tom Schneider wrote: |
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
|
|
|
|