This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem in data acquisition of ADS8330

Other Parts Discussed in Thread: ADS8330

We are using ADC ADS8330 in our project for data acquisition for sampling data at rate of 1Mhz.

We are facing a problem wherein sometimes the EOC signal always remains high  and sometimes it does not stay low for required duration i.e. 18CCLK's

 

The procedure for generating the control signals is explained below.

The conversion clock for ADC is the Internal Osc clock of 21Mhz.

 

Points considered for generating the control signals inside FPGA:

1. The minimum time between two consecutive CONVST signals is 21 CCLKs (conversion clocks)i.e. > 900 ns    FPGA is generating convert start every 1usec

2. A low CONVST  pulse of 100ns.

3. assert the chip select line ( active low) 

4. 40ns delay between falling edge of CONVST and rising edge of SCLK

5. SCLK frequency  is 25Mhz. sampling the data on the falling edge of the SPI clock

 Note: we are not checking the EOC since we have already maintained the timing between issuing two consecutive convert start as > than 21 CCLK.

 EOC should be generated from ADC after a convert start is issued

 

Can you please provide some solution or inputs for solving this.

 

Regards,

Priya.

  • Hi Priya,

    If I'm not mistaken, you have been discussing your ADS8330 problem with Prasanna.  The varying EOC implies that you are out of sync somehow with the application of your CONVST input and the ADS8330.  Is it possible to get oscilloscope screen captures of your control inputs rather than the logic analyser plots that you provided?

    The issue you describe sound like there has been an incomplete reset of the device, either through normal power up or a brownout condition.  The schematic Prasanna sent us shows the SDI line being pulled high.  Is it possible to wire SDI into your FPGA?  This would allow you to read the configuration register and verify its status as well as issue a software 'reset' to the device.

  • Hi Tom,

    Yes we were discussing the same issue with Prasanna.

    We were also of the same opinion that the application of CONVST is not in sync with the internal ocillator clock since on few power cycles the ADC does acquire proper data..

    The one thing we experimented now is:

    1. Generate a dummy convert start.

    2. Wait for the EOC rising edge and generate the next convert start after 3CCLK period.

    3. The chip select and data reading is as per timing diagram.

    This way the application of convert start will be in sync with the internal oscillator clock.

    Do you think this would be the right way of doing it or you have anything to add to this?

    We tested a file with the above logic and it seems to be working, although we need to check it for more number of iterations.

    Please Comment.

    - Priya

  • Hi Priya,

    Yes, that approach would put you in SYNC with the internal CCLK, at least initially.  Can you adjust your application of the CONVST input so that you wait four CCLKs instead of three?  That would slow your overall throughput a little, but it should give you margin over temperature if the internal CCLK frequency drifts a little.

  • Hi Tom,

    We have implemented the following steps in our code:

    1. Generate a dummy convert start.

    2. Wait for the EOC rising edge and generate the next convert start after 3CCLK period. If no EOC go back to step1 after a timeout of 50usec.

    3. The chip select and data reading is as per timing diagram.

    This way the application of convert start will be in sync with the internal oscillator clock.

    However, we notice that even with this the EOC sometimes remains high ( 1 in 10 iterations of power cycle)

    Can you please suggest something.

    Note: Our baords are already under production so we didnt want to experiment tying the SDI line to FPGA and

    checking the status of configuration registers or providing a software reset.

    We had decided to work with default mode configuration and tie the SDI line to high since we were short of FPGA pins.

    - Priya

  • Hi Priya,

    The only other possibility that I can think of is that somehow your getting a partial power on reset (POR) perhaps caused by a glitch on the analog supply to the ADS8330 during your power cycle.  This could explain some of the weird behavior you are seeing.  Can you probe the chip supply with an analog scope and see if you have any pertabations there?

  • Hi Tom,

    1. we are using VCC = 5V and the min voltage of the VCC on the board is 4.97. The POR condition will come at 1.5V but our analog supply is not going below 4.97 at all condition.

    2. We are not reading the data immediately after the power on from the ADC. Loading the code on the FPGA is taking 30 to 40 seconds. After that only we are reading the data and that time the power is in stable condition.

    Regards

    Priya

  • Hi Priya,

    What I've noticed in the lab is that when I power cycle the ADS8330 quickly, by that I mean that I am not allowing enough time for both the analog and digital supplies to collapse,   If the digital supply has not gone to zero, I can see similar 'strange behavior' in the EOC output strobe.  I can see cases where EOC does not toggle at all, or has inconsistent low times which look like synchronization problems.  When you have these problems, is it immediately from power on or only after a power cycle?

  • Hi Tom,

     

    it is on both the time. when we initially start the board and when we do power cycling. We are not switching OFF and ON the power supply very quickly. We take approximate

    5 seconde for one power cycle to another power cycle and i think this time is enough for the supplies to get reset or reach to the ZERO.

  • Hi Priya,

    Can you grab oscilloscope captures of both the analog and digital power rails?  There is a depiction of the POR (power on reset) sequence in the back of the data sheet (page 37).  The analog rail has to be at below 125mv for 350ms to properly trigger this circuit.