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.

  • Resolved

ADS1278: ADS1278 data shift in SPI mode for Vin > Vref/2 on first channel

Prodigy 20 points

Replies: 3

Views: 129

Part Number: ADS1278

After seeing what I initially thought was a glitch in data collected through an ADS1278 ADC, after much testing I believe I am seeing a shift in the output data but cannot explain why.

Test setup: I am using the ADS1278EVM-PDK. The MMB0 is used only to power the ADC board, the data header is not connected between the boards. I am reading data via the SPI interface into a microcontroller on a different board. The ADC is using the on-board reference, an off board clock, buffers bypassed. I am feeding it with a single ended input with AIN- tied to VREFP (though have tried other setups there, that doesn't seem related). I am primarily using high resolution mode but have tested all 4 modes and all 3 SPI formats. CLK and SCLK are not synchronous.

Failure condition: I am able to read data without any issues except under the following condition: when the differential input voltage exceeds Vref/2 (codes 0x400000 to 0x7FFFFF) on the first enabled channel. It never happens when the diff input voltage is < Vref/2. And it only happens if this voltage appears on the first enabled channel for a given data bit (ch1 in TDM:fixed, first enabled channel in TDM:dynamic, all channels in discrete format). This behavior is extremely consistent (never happens without this condition). The frequency of bad samples seems to increase with sampling rate (few a few times per second to hundreds). I have tested many combinations of SPI clock and ADC clock speed, as well as all 4 ADC operating modes. The problem is present in all cases given the above condition, but seems more likely to occur at high sampling rates. I have been primarily testing with 6 or 12MHz clocks.

Observed behavior: When the problem occurs, the entire contents of the data register appears to be shifted left one bit, with the exception of the first bit (high bit of first channel), which is always 0. All channels are shifted left one bit, though only the first will have the top bit set to 0, regardless of the "shifted" value. 

Conclusions: I have observed the SPI lines with a logic analyzer for a few of the bad samples and the value on the lines appears to match what is read by the microcontroller. I have been initially investigating this as an error in my implementation of the microcontroller SPI interface but the behaviors I've seen don't seem to agree with that. Namely that the behavior depends on the input voltage level and what channel that voltage appears on. The microcontroller reading a series of bytes over SPI should be indifferent to those conditions.

If there is an ADC timing condition I am violating, I have not been able to determine it. There is a 1 t_CLK minimum duration between DRDY falling and the first SCLK rising edge. My microcontroller averages around 2us and isn't capable of responding in < t_CLK (83ns). There is a note in the datasheet about SCLK/CLK being a power of two ratio for "best performance" (though that doesn't seem to be defined). Changing that ratio doesn't seem to change the rate of errors, though the clocks are not synchronous (I didn't see that stated as a requirement anywhere and haven't been able to test that yet).

Any insight into what I am doing wrong here would be greatly appreciated.

  • Hi Jonathan,

    Welcome to the TI E2E Community!

    First, thank you for the detailed information.  Under your test conditions, I assume you have AIN- tied to VREFN, which is the board analog ground.  Since you are only reading positive values, the MSB should always read 0 for a positive 2-s compliment code.

    It seems like there is some kind of timing violation.  From your description, I assume you can just enable a single channel and observe the failure mode?  Please send a picture of the waveforms for /DRDY, SCLK, and DOUT for the entire SPI transfer frame.  Also, a picture of the schematic showing all of the pin connections will be helpful to understand the exact configuration of the device.  A logic analyzer output is a good start, but it would be preferable to capture the waveforms on a scope to see if there is any excessive ringing or slow rise/fall times.

    Regarding the synchronization of the CLK and SCLK, this is only needed to get the optimal noise performance; it is not necessary for proper communications.

    The ADS1278 launches the DOUT MSB on the falling edge of /DRDY and the rest of the bits on the falling edges of SCLK.  When using SPI mode, the maximum CLK rate is 27MHz, which limits the maximum output data rate to 105.5ksps.  As a result, the maximum SCLK is also 27MHz.  

    Keith Nicholas
    Precision ADC Applications

  • In reply to Keith Nicholas:

    Unsurprisingly, it turned out to be an issue with my setup. Once I updated my test setup to detect the errors using the microcontroller and generate a trigger for the scope I was able to see the issue (or at least the result). When the shift error occurred, the second bit of the output only went high for about a quarter of a bit period. I was unable to ever see enough ringing with the scope on the clock line that could cause that, but I assume the ADC was seeing it and this caused an incorrect shift. I made some modifications to the wiring to improve the ground connection between the boards and that resolved the issue. I still am not entirely sure why this only ever manifested on the rising edge of the second bit and never anywhere else, but it seems to be fixed now. Sometimes those really specific behaviors distract you from the more obvious problem.

    Thanks for you help.

  • In reply to Jonathan Williams:

    Hi Jonathan,

    I am glad to hear that you got it working!  Signal integrity issues can cause so many different failures, it is hard to predict how they will appear.

    Thanks for the update.


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.