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.

ADS131M08: ADS131M08 strange behavior of DRDY

Part Number: ADS131M08

Hi guys.

We are using ADS131M08 ADC. XTAL1 connected to external quartz resonator at 8.192 MHz
We need read 2000 samples per second (data reading in every interrupt by DATA READY pin).
Registers settings (SPI 8 MHz):
I (1327) ads131_read_reg: reg 0x00 val 0x2801 // ID
I (1337) ads131_write_reg: reg 0x03 val 0x3f12 // CLOCK: use 6 channels, oversampling 2048
I (1337) ads131_read_reg: reg 0x03 val 0x3f12
I (1347) ads131_write_reg: reg 0x02 val 0x110 // MODE: clear reset bit in STATUS register
I (1347) ads131_read_reg: reg 0x02 val 0x110

Interrupt handler:

uint32_t adc_int_counter = 0;
int32_t tempvals [6];
int32_t tempvals2 [6];
static void gpio_isr_handler (void * arg)
{
  adc_int_counter++;
  extern uint16_t ads131_status;
  // function send&read ADS131 frame (3 * 10 byte): STATUS register + converted to signed 32 bit MEASURES for 6 channels
  ads131_read_measures (&tempvals[0]);
  if (adc_int_counter<10)
    ads131_read_measures(& tempvals2 [0]); // additional reading for clear ADC internal FIFO after start
}

nDRDY signal:
yellow - DATA READY
red - SPI CS

Sometimes nDRDY signal becomes incorrect (1 us peaks instead of meander) (status register value 0x13f):

nDRDY correct if generate only 1000 samples per second (OSR 4096).

The signal is valid if use the following handler:

static void gpio_isr_handler (void * arg)
{
  adc_int_counter++;
  extern uint16_t ads131_status;
  ads131_read_measures (&tempvals[0]);
  if (ads131_status & 0x3f) !=0)
  {
    ads131_read_measures (& tempvals2 [0]);
    adcDataEqual = memcmp(tempvals, tempvals2, sizeof(tempvals)); // !!! STRANGE: WHY DATA IS EQUAL !!!
  }
}

Correct nDRDY signal:

Incorrect nDRDY signal:

Why do the DRDY0-DRDY5 bits of STATUS register appear again despite the permanent reading data in interrupt? And why second read data equel first read?
Why does the nDRDY incorrect when only one reading in interrupt?

  • Hello Artem,

    I'm still reviewing everything that's happening here, but can you configure what you're triggering criteria is on your oscilloscope? It looks like your triggering on either edge of nCS when we should be only triggering on the falling edge of nDRDY.

    I also won't claim to be an expert with your code, but I want to confirm that your interrupt isn't time based.  The wrong way to make the interrupt is to wait 2000Hz to toggle nCS low and look for data because of clock jitter and the clock specification in the datasheet. Traditionally we expect to see nDRDY fall then which then triggers the interrupt to go look for data. I see a couple of frames on the video where there's no toggle of nDRDY on the screen but the nCS is still toggling anyways. This is confirmed that the good data always has nDRDY to the left of nCS but bad nDRDY signals can be wherever (but usually around the leading edge of nCS).

    Also, are you using our EVM? Do you have the GUI to compare the behavior against?  

    Best,

    -Cole

  • Thank for answer.

    I look behavior with a logic analyzer and found there are interrupt handling skips. This is not an ADC problem, but a microcontroller or code problem.

    Skips not occure if not call vTaskNotifyGiveFromISR() from interrupt hanlder.