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.

ADS 8330 interface problem

Other Parts Discussed in Thread: ADS8330, ADS8329


I am using PIC24HJ to retrieve data from ADS 8330. Manual trigger, Internal OSC clock.

The code is simplified as below trying to single out the problem...


unsigned int  SDIData; 
        unsigned int result;


        ADC_SPIBUF = 0x0000;        // select channel

         while (REG_SPIRBF == 0);   
        SDIData = REG_SPIBUF;      // clear buffer

        REG_CONVST = 0;            // conversion request, CONVST goes low

        while(ADC_EOC == 1);    // CONVST back to high after EOC goes low
        ADC_CONVST = 1;

        while(ADC_EOC == 0);    // End of conversion when EOC goes high
        REG_SPIBUF = 0xD000;        // request to read data

        while (REG_SPIRBF == 0);    //Receive buffer flag
        SDIData = REG_SPIBUF;      // read


I cant receive any data  (reading is zero). I can read CFR correctly though when send out 0xC000 instead of 0xD000;

From OScilloscope,

1)  NO response is observed from SDO while retrieving data

2) EOC pulse width (time when EOC at LOW level) = 800nsec ,  thus I assume conversion is completed properly?

3) CS pin -- there is only one pulse during conversion. Do I need to generate another one (with a falling edge of CS) to read data? CS seems only controlled by SPI module of PIC24.

Anybody can help? Thank you!

  • Well, I made some changes on configuration and code. Still the only result received from ADS8330 is either 0 or 65535 (FFFFh). It is not a u-processor problem because the scope does show all "0" or "1" at SDO, after all, CONVST, SDI, CS and SCLK respond correctly according to datasheet.

    1. CS=0

    2. send "0x000": select channel

    3. some data received: clear SPI buffer, CS=1

    4. Start conversion: CONVST goes low, then high again after certain time >40ns

    5. wait till End of Conversion (EOC goes high)

    6. Send "0xD000" to read data

    7. CS=0 (to generate a falling edge)

    8. Read data


    I think something is wrong or missing at 6,7,8 step. Can anybody clear this up for me? Thank you!

  • Hi Kindalate,

    Can you post your O'scope captures?  By the sound of it, you are doing what you need to do with the control inputs - pulsing the CONVST low, waiting for EOC, setting FS/CS low and then sending 0xD000 is correct.  The FS/CS line has to toggle high to low with the start of every transmission, so long as it is low during your read routine, you should be getting data from the device.  What is the reference voltage set to and what is the level of your analog input?

  • Hi Tom

    Reference voltage is 5V and input level is around 2.5V for the testing

    here are photo I took from scope, hope they help

    ADS8330_SDO (data)





  • Kindalate,

    I was hoping to see a little more detail.  I've attached a little document for you that shows the relationship of SDI to SCLK and FS/CS in an ADS8330 setup that I use.  In my case, I have a low dwelling SPI clock (please note that the SCLK input is filtered so it looks sinusoidal - it really is a square wave though).  If you can get hold of a multi-channel scope, please try to verify that your input commands are valid on the falling SCLK edge.  Also, let me know what the date code is on the parts you are having trouble with.  There should be three lines of text on the surface of the package - if you can let me know what they are, I would appreciate it.

    Configuring the ADS8330.pdf
  • Tom, Thank you!

    I did the test again trying to present the data in similar format as you have shown and here are the new screen shots I captured, see if they could provide enough information.


    The first 5 pictures are latest

    #1. SDI(yellow) + SCLK(blue): when 0xD000 was send out

    #2. SDi(yellow) + SCLK(blue): when 0xC000 was send out

    #3. CS(yellow) + SCLK(blue)

    #4. SDO(yellow) + SCLK(blue): reading CFR (6FF) 

    #5. SDO(yellow) + SCLK(blue): reading Data (zero)


    The three lines on the chip surface are: ---"TI ADS"---"8330 I"---"8595"---. Is that what you are referring to?


  • Humm...

    So the date code thing, the information you provided is what I was looking for.  There was a timing change in the silicon in late 2007 and I wanted to be sure you were not using the old chips - you are not.  The device you have is from May of 2008.  The clock polarity/phase relationship looks fine, so long as you are strobing data on the failing edge, the clock can dwell high or low.  Since the device responds to the read CFG command, you must be able to talk with the device - the default read back should be 0xFFF so it looks like it is taking your write CFG command and setting the channel selection to manual mode.

    The only ting left is the analog input and the reference.  Can you please double check your connections to +VA, REF+, and the +IN0/1?  The REF- and COM pins need to be tied to GND - AGND and BGND should be tied together at the chip.  Is this problem present on multiple boards?  Have you tried replacing the ADC on the off chance that you might have damaged the analog input section of the device?

  • I used two cards for the testing and both have similar result. I may overlook some important part when design it. I will look into it next. Please check your email.

  • For those interested parties - Kindalate and I have been conversing off line a little.  The issue turns out to be a problem in which the ADS8330 cannot access the +IN1 input. 

  • Tom, Please clarify whether the issue is with the ADS8330 or Kindalate's circuit design, and what would cause it to not access the +IN1 input.  Would the same thing affect the AD8329?



  • Hi Dan,

    Actually Kindalate found a way to modify the internal fuses in the device.  The fuse which controls the multiplexer was damaged and therefore basically disabled CH1.  This would not happen in the ADS8329 since it is already a single channel device.