• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 47 subscribers
  • Views 343 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADC3663: ADC output problem after power down and then up

John Jiang1
Prodigy 100 points
Part Number: ADC3663

I am using ADC3663IRSBT to simultaneously acquire two channels at 50MHz. From DFT result, I noticed that 20% of time, the phase difference changes about 5 degrees for a sinusoidal wave of 2MHz. To figure out the problem, I set the ADC into ramping up mode with step of 1 so that I can know the exact number I would get. After many tests, I found the reason is related to the unstable behavior of ADC after power down and then power up. The following is my test results:

“ADC power down”: using PDN/SNC pin or SPI command to power down ADC so that it won’t consume power

“ADC power up”: using PDN/SNC pin or SPI command to power up ADC for acquisition

“ADC Reset”: using SPI command to reset ADC to default register states and then initialize registers as 16-bit 2 wire ramping up mode with step of 1

 

Test 1: power up the board, then “ADC power up” , then “ADC Reset”, never “ADC power down” or “ADC Reset” again; in this case, there is no error and ramping ADC number received correct after hundreds starting acquisition; each acquisition will start and then stop FPGA synchronization/acquire interface; this proves that issues are not from FPGA

 

Test 2: power up the board, then “ADC power up” , then “ADC Reset”, then for each acquisition, "ADC power up" and “ADC RESET” at the beginning of each acquisition, and “ADC power down” at the end of each acquisition; among hundreds of acquisitions, the error is about 40% (when error happens, all data are not correct in that acquisition); if I only do "ADC power up " and “ADC RESET” , not do “ADC power down”, the error rate is about 1%, but error still exists; if I only do “ADC power up” and “ADC power up”, once error starts, it will never recover from error  even after many “power down” and “power up”.

 

From above test, it seems that after power down, the ADC can not work properly after power up and even with "ADC Reset", or maybe something related how I do “ADC Reset”? the following is my reset code. Another possibility is that I did not have any connection to RESET pin of ADC since it has internal pull down resistor, can that be a issue? or do I have to toggle the hardware "RESET" pin so that the ADC can work properly?

 

     //reset ADC

        AD_write_reg(0,  0x01);

        vTaskDelay(100);

        //2-wire configuration --------------------

        AD_write_reg(0x07,  0x4B); //16-bit, 2-wire

        vTaskDelay(2);

        AD_write_reg(0x13,  0x01);

        vTaskDelay(2);

        AD_write_reg(0x13,  0x00);

        vTaskDelay(2);

 

        AD_write_reg(0x0E, 0x08); //select internal REF with SPI

        vTaskDelay(2);

        AD_write_reg(0x19, 0x10); //Config FCLK frequency  2-wire decimation bypass,  D7:0; D4:1; D0:0

        vTaskDelay(2);

        AD_write_reg(0x1B, 0x88); //Config FCLK frequency bypass decimation, 16-bit, D7:1; D5-3:001

        vTaskDelay(2);

 

        AD_write_reg(0x8F, 0x02); //ch0 change output format to be offset binary

        vTaskDelay(2);

        AD_write_reg(0x92, 0x02); //ch1 change output format to be offset binary

        vTaskDelay(10);

 

I have been struggling to figure out what is the issue for couple of days. Help is appropriated.

 

  • 0
    TI__Genius 15321 points

    Hi John, 

    I am checking into this and will get back to you soon.

    Regards, Amy

  • 0 in reply to John Jiang1
    TI__Genius 15321 points

    Hi John,

    I am still checking into this. Meanwhile, try to give at least one reset pulse after clk is fed.

    Regards, Amy

  • 0 in reply to Amy
    Prodigy 100 points

    Hi, Amy:
         As I noted previously, there is no connection to the "RESET" pin of ADC, so I currently only use "software reset" by sending a SPI reset command.

  • 0 in reply to John Jiang1
    TI__Mastermind 23760 points

    Hello John, 

    Have you tested running SPI at a much lower speed? What frequency is the SPI operating at? Also, what is the unit for your vTaskDelay()? If in µs, this could be a problem after the initial reset since the part initialization shows a delay of around 200000 clock cycles before any following register writes. If the units are in ms, the timing is ok.

    Thanks

  • 0 in reply to Chase W
    Prodigy 100 points

    vTaskDelay unit is mS. The SPI is generated from gpio pin and the speed is very low and I also tried to delay 1mS between each clock. There is no difference.

  • 0 in reply to Chase W
    Prodigy 100 points

    I also read back the registers after writing and their reading values match the writing values.

  • 0 in reply to John Jiang1
    TI__Mastermind 23760 points

    Hi John, kindly see my comments in red:

    Test 2: power up the board, then “ADC power up” , then “ADC Reset”, then for each acquisition, "ADC power up" and “ADC RESET” at the beginning of each acquisition, and “ADC power down” at the end of each acquisition; among hundreds of acquisitions, the error is about 40% (when error happens, all data are not correct in that acquisition); if I only do "ADC power up " and “ADC RESET” , not do “ADC power down”, the error rate is about 1%, but error still exists; if I only do “ADC power up” and “ADC power up”, once error starts, it will never recover from error  even after many “power down” and “power up”.

    Can you please explain and show what the incorrect data looks like in this mentioned situation?

    From above test, it seems that after power down, the ADC can not work properly after power up and even with "ADC Reset", or maybe something related how I do “ADC Reset”? the following is my reset code. Another possibility is that I did not have any connection to RESET pin of ADC since it has internal pull down resistor, can that be a issue? or do I have to toggle the hardware "RESET" pin so that the ADC can work properly?

    The hardware reset is not required - only performing the software reset is not a problem. At any point, is the clock signal removed/disabled from the ADC prior to reset? I am wondering if the clock is not present during the software reset for some instances. The clock presence is mandatory before toggling reset via either a hardware or software reset. This is crucial for the device to reset all internal functions.

    Regards, Chase

  • 0 in reply to Chase W
    Prodigy 100 points

    Hi, Chase:

          After I found that AD values were not correct, I have been using ramping up mode with step of 1 to test. When error happens, the received AD value is not in the sequence of step of 1 and the values are jumping around. When it works, the AD values is ramping up with step of 1 constantly. 

         The master clock to ADC is always present after power up since the oscillator is connected to +3.3V supply. 

          Do you have an evaluation board to also do the software reset and ramping up test to see whether you have the same symptom?

  • 0 in reply to Chase W
    Prodigy 100 points

    The +3.3V oscillator clock is passed to FPGA and FPGA output the same 50MHz clock with I/O of 1.8V which is the same as AD. Once power up, it keeps running forever.

  • 0 in reply to John Jiang1
    TI__Mastermind 23760 points

    Hi John,

    Yes we have hardware in our lab which can be used to verify this. Can you zip up your SPI sequence and upload here so someone in our lab can take a look using 50MSPS sample rate? Also, I am specifically interested in seeing the data for when the error happens, your description "jumping around" is not clear enough for us to understand exactly what is happening, it could be jumping around by 2 codes or it could be jumping around by 20k codes. Can you attach the raw data as well please?

    Regards, Chase