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.

ADS131A04: Fault ADC input & Fault SPI

Part Number: ADS131A04

Hi all,

I am working with the ADS131A04 hooked to a Raspberry Pi 3 and I am having some troubles while getting the data. I have the ADC configured in the following way:

-AVDD, Refext and RefP 5V from the Raspberry

-AVSS and RefN to GND

-SPI synchronous slave mode

-Digital Supply 3.3V from the Raspberry

The register configuration is done correctly, without activating the internal reference pin (INT_REF) and using the external clock.

Once the setup is finished, I take 10000 samples sending a NULL command (0x00) and this should return a RREG(STAT_1)  and following this, the 4 channels data. I am only using the first channel at the moment, and, even though I haven't tested if the returned data is correct, it looks promising. The following picture is a test that I did fiddling with the knob of a power supply

However, the RREG(STAT_1) keeps giving me two errors for every sample: F_ADC and F_SPI bits are set. Following the datasheet, I read the STAT_P and STAT_N registers to see which channels are exceeding the threshold and I get a 0x0F in return for both of them, meaning that all channels are exceeding the positive and negative inputs. I have 2 channels grounded, 1 channel floating and 1 connected to the power supply as an input. 

- Do you know why all of the channels are giving me this error? Because as it can be seen in the graph, the values that do not reach the limits should not return any errors. (BTW I have the comparator threshold setup to 95%) 

Regarding the SPI, when I read the STAT_S register, it is telling me that I have an error with F_CS and F_FRAME and I can't figure out why. I am using an external 16.384 MHz crystal oscillator and both clock dividers CLK_DIV_14 and ICLK_DIV_14. 

I hope you can help me find some solution to this. Let me know if you need any more information on the setup or the code.

Thanks in advance,

Unai

  • Hello Unai,

    The percentages in the COMP_TH[2:0] bits represent percentages referred to the analog supply rails. For example, the high-side comparator threshold will trigger at 5 V x 0.95 = 4.75 V above AVSS if the threshold is set to 95%. Likewise, the negative input comparator will trigger at 5 V x 0.5 = 0.25 V in this circumstance. Note that this is not related to the voltage between the inputs, but only the voltage of the individual input pins relative to the power supplies. It is possible to have a situation where the comparator triggers but the conversion result is still well within the range of the ADC. Below is an example:

    COMP_TH = 000 (95%/5% trigger)

    AINP = 4.8 V (triggers comparator)

    AINN = 4 V

    Data output = AINP - AINN = 0.8 V

    You said that your inputs are either tied to ground, tied to the positive supply, or floating. In the scenarios where the inputs are tied to AVDD or AVSS, this will always trigger the comparators. When the inputs are floating, this could trigger the comparators because the inputs are in an unknown state. Does this make sense?

    Regarding the F_CS and F_FRAME faults, those are interface faults. Can you capture the SPI during a sample collection and post the image here? That is the only way I'll be able to tell what is wrong.

    Brian

  • Hi Brian,

    Thanks for the fast response. I have been doing some more tests and it looks like you are quite right regarding the ADC range.

    For the SPI, I have the following pictures (I only have 2 channels in my oscilloscope so I replicated the same signal various times)

    I have the 24 bit word option selected, so I am sending the NULL command 15 times to get 1 status word + 4 channel data words (5 words x 3 bytes each)

    -Channel 1: CS, Channel 2: SCK

    -Channel 1: Dout, Channel 2:SCK

    -Channel 1: Dout, Channel 2: SCK (less zoom)

    I haven't uploaded the Din signal, because it is always 0x00. Howevere, let me know if more information is still needed.

    Also comment that even though the SCK signal is running at 625kHz, I have also tried it at ~10MHz with the same fault.

    Thank you,

    Unai

  • Hello Unai,

    Is DRDY tied to CS or is that signal driven differently? Remember that the DRDY pin must be deasserted during the exact clock cycle that the device expects in synchronous slave mode. The F_CS fault only occurs when SCLK is high when CS transitions. Does that ever happen in your communication routines? Even perhaps by accident?

    Brian
  • Hello Brian,

    Yes, DRDY is tied to CS. I have been checking and CS always transitions once the SCLK is low. What do you mean when you say that the DRDY pin has to be deasserted during the exact clock cycle? As you can see in the post above, the CS pin goes high  when the SCLK is not running anymore. Do you think that might be the problem? Can I ignore that error then?

  • Hello Unai,

    In synchronous slave mode, the DRDY input must be synchronized to the internally programmed data rate that is configured in the registers. This usually means that the host has to either source or have access to the ADS131A04's master clock in order to stay synchronized. Is this the case?

    Brian
  • Hello Brian,

    So, if I understand this correctly, I will need to create a clock signal at 84kHz (16.384MHz / CLK_DIV_14 / ICLK_DIV_14) and then use this to drive DRDY. The master clock for the device is the crystal oscillator, so I think it will be easier to source it from the Raspberry. I will try to do this and I will get back to you if I need anything else.

    Thanks for your responses
  • Hello Unia,

    The signal you use to create DRDY must be synchronous to the master clock for the interface to work properly. Alternatively, you could interface with the device using asynchronous interrupt mode. That mode most closely resembles a traditional SPI interface. You may have to adjust the hardware slightly to adapt to the different pin functions.

    Brian
  • Hi Brian,

    As you suggested, I am now using the asynchronous interrupt mode, but I am still getting the F_SPI fault, and when I read it it tells me that the fault is in F_FRAME. Now, my code waits until the DRDY goes low and then does the reading as you can see in the following pictures:

    Channel 1: DRDY, Channel 2: SCK 

    Channel 1: DRDY, Channel 2: Dout

    So, as I understand here, the error is telling me that the SPI clock is not fast enough for each frame, but I see that both SCK and Dout are fully sent before the DRDY sends another signal. Could you clarify what the F_FRAME error means?

    Thank you

  • Hello Unai,

    The F_FRAME fault has a slightly different meaning than that. It means that not enough SCLK periods were sent for a given frame. Can you verify that you are sending the proper number of SCLK periods before bringing CS high?

    Brian
  • Hello Brian,

    I have configured the ADC for 24 bit words, with dynamic frame size without CRC.

    From there I get that I need to send 5 words with 24 bit length each. The library I am using sends the words in bytes, so I send 3 bytes for each word, 15 bytes total. I have also checked sending 30 bytes and the Dout stops sending information after the 15th word, so I am guessing that all the info is being sent with those 15 bytes. Also, sending 30 bytes, the same error appears.

    Unai

  • Hey Unai,

    Can you please send me your schematic?

    Brian
  • Hello Brian,

    Here it goes, hope it results useful. Just as a note, all the GNDs are common.

    Unai

  • Hello Unai,

    The schematic looks correct for 24-bit data output with asynchronous interrupt mode.

    The F_FRAME error is triggered when an internal SCLK edge counter does not sense enough SCLK periods (in this case at least 120) from when CS is taken low to when it is taken high. There must be something in the communication routine that is not meeting these parameters. I think we're sure that SCLK is coming enough times (in some cases more than enough). Perhaps we should look at CS - your last images show DRDY but not CS. Is it possible that CS is coming high early? The only other thing I can think to review is the register settings to make sure the device is configured how we think. When you review the register settings, make sure that they are read back from the device to rule out an error in the process of writing the registers.

    Brian
  • Hello Brian,

    I have changed the code to check the registers in the setup and they are well configured. I also manually send the read register command and see that they are well configured (just in case). 

    Regarding the CS, here two pictures.

    -Channel 1: DRDY, Channel 2: CS

    Same picture with more zoom:

    As you can see, the CS brings up the DRDY after 340ns. Right now I am using CLK_DIV_4, so Ficlk = 4.096 MHz. According to the datasheet, the propagation delay time between CS and DRDY should be maximum 2 times the Ticlk (~490 ns), and in this case this requirement is fulfilled. 

    Unai

  • Hello Unai,

    This is a tricky issue! I appreciate your patience. Eventually we will figure this one out.

    When you read the data, does the data you read make sense? Or is it really large or really small compared to what you think you should be getting? I'm trying to figure out if perhaps a bit is being shifted unintentionally in communication and that is what is causing the device to think you are not sending enough SCLKs. Do you have your SPI settings as CPOL = 0, CPHA = 1?

    Regards,
    Brian Pisani
  • Hello Brian,

    The SPI setting is configured as CPOL=0 and CPHA=1 (mode 1). Regarding the reading of the data, I realized that something might be wrong. If I input a wave signal (~1,2kHz 5V)  it will capture the figure quite well. But when I input a constant voltage the output seems a bit off. I am having some trouble with my oscilloscope and this needs a little more testing.

    I have tried inputing a 2.34V value (from a power source) with the internal reference VREF_4V, this gives an 58.55% of the 4V. When I do the reading I get a 57.1%. It is a little off but doesn't look too bad as to have a shifted bit. 

    I will try to do more test with different values tomorrow and will come back to you.

    Unai

  • Here a couple pictures of a test  I made. Using internal 4V reference and as an input 2.5V from a regulator. Sampling rate at 8 kSPS. Vertical axis in Volts and horizontal axis in microseconds.

    Same figure but with zoom

    Unai

  • Hello Unai,

    This looks pretty close to what you expect right? Have you measured the source with a multimeter to see the voltage and noise of the source? It may not be exactly 2.5 V and it will definitely not be noise free (to capture noise you may need an oscilloscope or at least the "ac couple" feature on a multimeter).

    Also keep in mind that the ADS131A04 does not have very high input impedance. If the source does not have much bandwidth, you may see some issues with linearity. Typically we recommend buffering the inputs to the ADS131A04 to account for this.

    Regards,
    Brian Pisani
  • Hi Brian,

    Sorry for the late response. I guess the values are quite similar what I am expecting, and when I tried it with a signal generator, the output is even  better. However, what should I do with the F_SPI fault then? Just ignore it? It looks like the values make sense, and looking at the oscilloscope everything looked correct.

    What is your suggestion?

    Unai

  • Unai,

    I would say at least for now it does not seem to be causing any issues for you. Perhaps just continue on with your development for now. Maybe later you will see some problem later in your development and trace it back to this issue and then we can understand why this is happening. Like I said before - there must be something causing it. I will also see what I can do on my end to figure out why this could be happening.

    Brian
  • Unai,

    One last question that I don't think I've asked you yet: when you get the F_SPI bit, do you read the STAT_S register every time and the fault persists? The fault will only clear if you read the register.

    Brian