AD7276 missing codes

I am struggling to understand why our AD7276 fails to resolve data ending in 010 or 101.  
  AD7276 (6 pin version)

  3.3V VCC
  Host processor: Atmel SAMG55 J19
  Host firmware: Atmel ASF 3, SPI through DMA
Test setup:
  In the examples below, we ran a 0.5 to 3.0V DC ramp into the ADC input at 0.01Hz.
  We sampled 100,000 rows of data, with the ADC SPI clock running at 10MHz,
  Each sample consists of 14 consecutive ADC conversions.

  The purpose of the above setup was to make certain that, for a given input, we have reliable conversions, as the AD7276 used in our pulse-height-measuring instrumentation reportedly has missing, or highly-attenuated data within a given 14-conversion read sequence.

We have been able to reproduce this artifact and it is illustrated below.

Figure 1 is a screen shot of our analysis chart.  It clearly points out the missing conversions.
Figure 2 shows that as we enter a lower ADC input voltage region, the number of missing conversions reduces
Figure 3 shows a fairly solid appearance, but there are still missing conversions and these appear within the 010 and 101 endings.

These diagrams were produced by populating each of the 14 reads (from an array) into the appropriate binary code (row).  The number in each of the 14 columns is the number of "hits" (raw data conversions) reported.  

Figure 1: missing code analysis.  2.86 to 2.91 volts.  Black areas represent binary states in which no data was registered.
Columns (l-r) missing count, binary, decimal, volts, reads 1-14.

Figure 2.  1.72 to 1.77V.  The number of missing rows reduces, however we can see a "spillover" effect to adjacent binary conversions.

Figure 3. 0.16 to 0.20V.  A few rows highlighted for emphasis.  We note that the 010 and 101 codes are still bothered, in that these are almost always greater in hit count than adjacent binary conversions.

I've examined everything we can think of within our immediate control.  This includes the SPI bus, the SPI setup, and settings in the SPI driver which allow us to change (a) DELAYBS, the delay from CS going low to the start of the SPI clock (from high to low), (b) DELAYBCS, the delay between each CS (controls the data rate by pausing between each CS), and DELAYBCT, which is a delay between consecutive transfers.  All timing measures well within specifications.

We definitely do not believe this is a problem in the device, but rather a problem either in our driver or hardware setup.

Seeking ideas, comments, critique, ect.

Thank you all.

Update Tags
[edited by: @skowalik at 3:55 PM (GMT 0) on 21 Nov 2019]

Top Replies

  • 0
    •  Analog Employees 
    on Nov 11, 2019 1:48 PM


    Can you please provide more details regarding your hardware setup for the AD7276?   For example are you using the ADI provided evaluation kit or have you spun your own design?

    Can you also please provide timing diagrams for your conversion and data interface signaling?   This will help us diagnose your problem.


  • Hello Sean.  Yes, I can provide all of this to you.  I'll need a few hours to get it packaged.  Hang on, and thank you!

  • Sean,

    Sorry for the delay.  My test hardware failed and it took a day to bring up a new system.  There are several screen shots to show. 

    The new system is a finished board for our instrumentation development.  For purposes of my tests it consists of an AD7276 with a REF1933AIDDCT providing precision +3.3V

    Here's a snip of the schematic.  

    This hardware is quite stable, with the SPI pins brought out to a 0.1" header. This attaches to my mother board, which also hosts an Atmel G55 xPlained board that is our host processor.  The ATSAMG55J19 processor is the same we are using in our instrumentation.

    The timing diagrams are screen shots from a ScanaQuad SQ200.

    My host SPI is configured as follows:

    SPI bus speed is 1MHz and we telling the SPI driver to read 14 bits.  

    My test code provides control over the number of bits the driver decodes and also can mimic resolution bit size ("conversion bits").  For my testing it's at 12, which means it has no effect upon the result.  "Bit shift" converts the 14-bit result by shifting it right by one bit.  We find with certain SPI mode configurations it's necessary to shift, otherwise the result returned is 2X the actual value!  In present case, we do not shift and returned values are good.

    The driver used is ASF3.  Phase and polarity are defined thusly:

    I am using "normal phase" according to the chart.


    For this test I captured two consecutive reads.  The table below are the results.

    And here is a capture of the ScanaQuad analyzer:



    (CS LOW to CLK HIGH=1uS)

    I note that CS goes high and after 45nS goes low, right in the middle of the last bit.    Concern here?

    The above does not illustrate our problem, and that is that above around 1.5V we do not get any conversion results that end in either 010 or 101.

    Since you asked for timing, the above is a hopefully useful representation.


  • 0
    •  Analog Employees 
    on Nov 14, 2019 1:14 AM in reply to ARSK1MGY


    A couple of things.

    1) Can you confirm what voltage you put into the data converter when you generated these timing waveforms?  Was it approximately 2.5V?

    2) The AD7276 is looking for the clock to idle HIGH and so you probably want to change your SPI configuration to CPOL = 1. 

    3)  Data is shifted out of the AD7276 on the leading edge (falling) and the datasheet assumes the hold time of the serial data output is sufficient for you to read the current value on that edge with the controller and thus I would make CPHA = 0 so that the data is sampled on that leading edge.  If you left CPHA = 1 I think you would need to do your BITSHIFT trick.

    4) Once you have completed 14 complete clocks the only timing requirement that needs to be satisfied with respect to CS is the minimum high time of 4ns as with your current clock period the converter acquisition time is satisfied.  Thus the narrow nature of the CS as you've shown is fact it is necessary to initiate the next conversion.

    My suggestion is that you try making the code changes to implement the configuration I've mentioned above.   Then for range of DC inputs around the area you had trouble before recollect some data and let me know how things look before and after.

    Hope this fixes your issue.


  • Sean,

    Yes.  Approx 2.5V 

    I will make these changes (Set CPOL to 1 and CPHA to 0).  Will post results.  Thanks!