• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 45 subscribers
  • Views 120 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.

ADS131M08-Q1: SPI communication when CS is permanently held low

Lukas Obkircher
Prodigy 70 points
Part Number: ADS131M08-Q1
Other Parts Discussed in Thread: ADS131M08

Tool/software:

Hello,

I'm currently working with the ADS131M08 and would appreciate any advice or tips regarding SPI communication with this device. My application requires reading data at a 16 kHz rate.

In my setup, the CS line is permanently held low. I'm able to read a full frame of 10 words successfully, but only if I wait for the SPI timeout (around 4 ms). If I attempt to read the data within that timeout window, I receive incorrect or "garbage" data.

To address this, I configured the DRDY pin as an interrupt trigger. When DRDY is asserted, I initiate SPI reading via DMA, and in that scenario, everything works reliably.

My goal, however, is to avoid using interrupts. I experimented with polling DRDY instead, but encountered the same issue with invalid data unless I read immediately when DRDY is asserted.

Is there a way to achieve consistent and correct data reads without relying on interrupts—maybe using precise polling or another method?

Thank you in advance for your support.

Best regards

  • 0
    TI__Mastermind 45785 points

    Hi Lukas,

    Can you please clarify "read the data within that timeout window"? do you mean reading the data between 0~4ms or longer than 4ms after the SPI communication started?

    BR,

    Dale

  • 0 in reply to Dale Li
    Prodigy 70 points

    I’ve noticed the device behaves consistently with the following pattern:

    • As soon as an SPI transaction begins, a 4 ms “timeout window” opens. Within that window I can read one full frame without issue. If I try to fetch a second frame before the 4 ms elapses, the data is corrupted. After the window closes, I can read the next frame and the cycle repeats.
    • Disabling the SPI‑timeout bit in the MODE register doesn’t help—only the very first frame is valid; everything that follows is garbage.
    • The one approach that works every time is to start the SPI read immediately when DRDY asserts. Initiating the transfer right away (instead of waiting) delivers correct data on every frame. This approach works only with the interrupts. 
  • 0 in reply to Lukas Obkircher
    TI__Mastermind 45785 points

    Hi Lukas,

    Firstly, ADS131M08 ADC normally uses the /CS signal as the start and end of the frame. When the /CS is tied to the ground, the ADC will count the number of SCLKs to check where the frame starts and ends for properly decoding the command and shifting out the data. For example, one frame requires one STATUS word+8 channel data+one CRC word=240 SCLKs, if you did not send a correct number of SCLKs, the data in next frame will be messed up.

    Secondly, if you have missed reading data, the data you are reading may not be the latest data. It depends on how many samples you have missed.

    Lastly, reading data when the data is ready is recommended, otherwise the data could be messed up when the conversion is ongoing. When the /DRDY is used as an interrupt to the MCU for reading data, you will not miss reading data and also you can maintain the data integrity, so using /DRDY to retrieve the data is always recommended.

    Regarding your configurations, you are reading the data once every 62.5us from16kHz, I'm not sure what the data rate you set on your ADC, but probably you have missed reading data or you are reading the data during the conversion. If you could share your continuous SPI timings with /DRDY signal together that are captured with a logic analyzer, I can check it for you.

    BR,

    Dale