• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 47 subscribers
  • Views 440 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.

ADS131E08: DRDY interrupt get stop

Harsiddh Patel
Prodigy 40 points
Part Number: ADS131E08

Hello,

I am working with ADS131E08 ADC. I have done ADC interface with one controller and I am using FreeRTOS.
ADC initialization is done before RTOS start scheduler.
Where I have two task, one task is for simple print massage other task is for read ADC data over SPI communication using (RDATAC mode). Both task has same priority.
Also I have configured external interrupt to detect every DRDY interrupt. I have configured CONFIG1 to 16kSPS DATA RATE.
In interrupt ISR I just increase one variable(whenever interrupt occurs count variable get increment).

In ADC read task monitor the count variable of ISR. If the count is greater then 0 then provide SCLK for 27 byte to read ADC data.
when ADC read task start run initially I am able to read data around 50 to 60 time but after certain of time ADC data is 0 and DRDY interrupt get stop.

Could you help me to find out why DRDY get stop from ADC?  

  • 0
    Prodigy 40 points

    Hello,

    I above issue is resolved, but now I am getting one invalidate data byte after some(around 50 or 60) validate data byte.

  • 0 in reply to Harsiddh Patel
    TI__Mastermind 18900 points

    Hello Harsiddh,

    What is invalid data mean? What value is it? Is it channel data or the STATUS word?

    Also, we are not experts on FreeRTOS and will not be able to help with anything code related outside of general debugging principles.

    Have you verified the data gathered by the MCU matches the actual data on the SPI line using a logic analyzer? If you're able to read correct data sometimes, then this indicates the ADC is working correctly and it is clearly a timing issue on the MCU side. If we can prove the ADC isn't working as expected, I may be able to help. Otherwise, if the ADC is working correctly, then this is a software question and I'm not sure I'll be able to help.

    Best,

    -Cole

  • 0 in reply to Cole Macias
    Prodigy 40 points

    Hello ,

    Thank you for your response.

    ===============================================================
    What is invalid data mean? What value is it? Is it channel data or the STATUS word?

    I have applied 0.0V DC in the input of channel 1. and was able to receive 0x003F1 Hex value of channel 1(24 bits) that is validate data. after receiving some validated data I received one 0x0FF345 Hex value(24 bits) invalid data.
    ===============================================================

    Below is the step that I have performed to configure ADC at power up.

    1. Reset sequence on the reset pin
    2. Send a SDATAC command
    3. Wait some time
    4. Offset calibration command
    5. Wait some time
    6. Write Configuration 1 = 0x92
    7. Write Configuration 2 = 0xE2
    8. Write Configuration 3 = 0xC0
    9. Write CHnSET 1to8 Register = 0x10
    10. Send RDATAC command
    11. Start pin high.

    In run time

    1. Wait for DRDY to interrupt
    2. Once an interrupt occurs read 27 bytes on SPI
    3. Convert the byte into word for Status as well as Channel
    4. Convert Raw word into volt
    5. print the volt on UART
    6. continue step 1

    Your help would be great to resolve this.
    Notes: Used 16ksps, Internal Vref 2.4V, External crystal oscillator 2.048Mhz.

    Once again thank you.

  • 0 in reply to Harsiddh Patel
    TI__Mastermind 18900 points

    Hello Harsiddh,

    Nothing inherently wrong as far as I can tell.

    As an unrelated side note, if you're doing input noise and offset testing, which is what you are doing when you apply 0V to the input, I recommend changing MUXn[2:0] to 001b. I don't know how you're applying 0V but wires will add impedance which might shift your reading in ways you might not expect and might not match the datasheet specs.

    Anyways, because nothing looks wrong, we have 4 general debug steps:

    • As mentioned above, change the MUX to short the inputs together internally and see if you get the same error
      • It will show that forcing externally is not causing an issue
    • Grab a logic analyzer and check if the SPI lines show a 0x0FF345 which means the MCU is correctly identifying the transmission
      • I'm not sure if you've already ruled out that your SPI commands are working as expected, but if you have. Then this is a pretty unlikely outcome. We still need to capture that data point as a sanity check
    • Force a known voltage, instead of 0V, on the input. See if the codes jump around as much as your 0V test
      • Going from uV to mV is pretty dramatic but not impossible. I'd cross reference with an oscilloscope to make sure what you see at the input matches what you see from the ADC (e.g. code spread or RMS noise of the voltage source) 
    • Use an oscilloscope to measure input with the 0V shorted
      • This probably won't help because we're trying to discern between uV and mV 

    Pick one or two, send the data back and let's see what you can find.

    Best,

    -Cole