ADS1259: ADC conversions returning duplicate values.

Michael Kruger

Part Number: ADS1259

Tool/software:

Hi,

We are using the ADS1259 to get a precise ADC measurement for our application. The ADC signal is used to measure the stabilization of the voltage of a measurement circuit. In short we send a start command to the chip, check for the conversion finished flag (Register 2 = 0x10) and then read out the value, we wait 250ms and repeat the measurement. Once the difference is within a tolerance we consider the circuit stable and use this for our measurements.

We have been using the chip like this for months on a few prototypes, but after shipping some samples, we ran into an issue were very occasionally the ADC measurement would return the exact same value a few times in a row. This would cause us to consider the measurement to be stable and we would fail our checks. Connecting an oscilloscope to this signal we clearly see the signal is still stabilizing, so it does not make sense for the value to be exactly the same especially since this is a 24-bit ADC.

It looks like the chip is not performing the measurement, and returning the previous measurement? Is this something that is known or are we using the chip incorrectly?

Thanks for your help!

Our Configuration for the registers:

#define ADS1259_REG_0_VALUE (0x05U) // SPI timeout enabled
#define ADS1259_REG_1_VALUE (0x50U) // Check sum enabled, sinc2 filter, external reference disabled
#define ADS1259_REG_2_VALUE                                                                        \
    (0x10U) // 10SPS (samples per second) (33.7 ms settling time), pulse control mode
#define ADS1259_REG_3_VALUE                      (0U)    // default value
#define ADS1259_REG_4_VALUE                      (0U)    // default value
#define ADS1259_REG_5_VALUE                      (0U)    // default value
#define ADS1259_REG_6_VALUE                      (0U)    // default value
#define ADS1259_REG_7_VALUE                      (0U)    // default value
#define ADS1259_REG_8_VALUE                      (0x40U) // default value

Our Conversion Sequence:

1. Send the start command (0x08)

2. Check whether the conversion is finished every 50ms by reading Register 2 until it equals 0x10

3. After reading register 2 about 4 times it equals 0x10

4. Read the data (0x12)

5. We check the checksum of the data and store the full 24-bit result.

over 1 year ago

0 Bryan Lizon86 over 1 year ago

TI__Guru 58861 points

Hi Michael Kruger,

It is not entirely clear what could cause this issue. Can you probe the ADC output with a logic analyzer to make sure the data you are getting from the ADC is actually identical to the previous result? In general, it will help if you can send us logic analyzer plots showing the communication before and after when this issue occurs.

-Bryan

0 Michael Kruger over 1 year ago in reply to Bryan Lizon86

Prodigy 10 points

Hi Bryan,

Thank you for your reply. I will try to capture some traces, but this will take me some time to arrange. I will post these when I have them.

Thanks again for your help.

0 Bryan Lizon86 over 1 year ago in reply to Michael Kruger

TI__Guru 58861 points

Hi Michael Kruger,

Understood, please respond back to this post when you have more info

-Bryan

0 Michael Kruger over 1 year ago in reply to Bryan Lizon86

Prodigy 10 points

Hi Bryan,

Apologies for the delay. We managed to capture an SPI trace of the initialization and measurement sequence. I have added it below with some annotations. The trace shows the ADC returning the same value for the measurement twice in a row, even though this is on an unstable signal where we expect it to differ before stabilizing.

I also uploaded the Sigrok/Pulseview file (the extension is changed from .sr to .txt to be able to upload it on this forum, so just change it back): ADS1259 Initialization and Measurements.txt You can use https://sigrok.org/wiki/PulseView to open it.

SPI Transfer Send Stop Command:
Sending: 0x11
Receiving: 0x00

SPI Transfer Initialize Registers:
Sending: 0x40 0x08 0x05 0x50 0x10 0x00 0x00 0x00 0x00 0x00 0x40
Receiving: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

SPI Transfer Readback Registers:
Sending: 0x20 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Receiving: 0x00 0x00 0x25 0x50 0x10 0x00 0x00 0x00 0x00 0x00 0x40

Start Command:
Sending: 0x08
Receiving: 0x00

Check Conversion Finished:
Sending: 0x22 0x00 0x00 0x00
Receiving: 0x00 0x00 0x90 0x00
Sending: 0x22 0x00 0x00 0x00
Receiving: 0x00 0x00 0x90 0x00
Sending: 0x22 0x00 0x00 0x00
Receiving: 0x00 0x00 0x90 0x00
Sending: 0x22 0x00 0x00 0x00
Receiving: 0x00 0x00 0x10 0x00

Read Data:
Sending: 0x12 0x00 0x00 0x00 0x00
Receiving: 0x00 0x3F 0xC7 0xA3 0x44

Start Command:
Sending: 0x08
Receiving: 0x3F

Check Conversion Finished
Sending: 0x22 0x00 0x00 0x00
Receiving: 0xC7 0xA3 0x90 0x00
Sending: 0x22 0x00 0x00 0x00
Receiving: 0x00 0x00 0x90 0x00
Sending: 0x22 0x00 0x00 0x00
Receiving: 0x00 0x00 0x90 0x00
Sending: 0x22 0x00 0x00 0x00
Receiving: 0x00 0x00 0x10 0x00

Read Data
Sending: 0x12 0x00 0x00 0x00 0x00
Receiving: 0x00 0x3F 0xC7 0xA3 0x44

0 Bryan Lizon86 over 1 year ago in reply to Michael Kruger

TI__Guru 58861 points

Hi Michael Kruger,

Unfortunately I am unable to download the Sigrok plot viewer due to corporate restrictions

Can you send me the plots as pictures? I appreciate you being as descriptive as possible with what you are showing, since I won't be able to zoom in or anything like that

-Bryan

0 Michael Kruger over 1 year ago in reply to Bryan Lizon86

Prodigy 10 points

Hi Bryan,

I tried to be descriptive as possible in the pictures below:

The formatting is messing up, but the order is:

First Measurement

Check the status of the data ready (read it every 50ms)

Last check and retrieve the data

Second Measurement Start

Check the status of the data ready

Last check and retrieve the data

As you can see the ADC returns the same value for both measurements.

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/first_5F00_measurement_5F00_command.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/first_5F00_measurement_5F00_read_5F00_busy_5F00_first.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/first_5F00_measurement_5F00_read_5F00_busy_5F00_second.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/first_5F00_measurement_5F00_read_5F00_ready_5F00_and_5F00_get_5F00_measurement.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/second_5F00_measurement_5F00_command.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/second_5F00_measurement_5F00_read_5F00_busy_5F00_first.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/second_5F00_measurement_5F00_read_5F00_busy_5F00_second.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/second_5F00_measurement_5F00_read_5F00_busy_5F00_third.png

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/73/second_5F00_measurement_5F00_read_5F00_ready_5F00_and_5F00_get_5F00_measurement.png

0 Bryan Lizon86 over 1 year ago in reply to Michael Kruger

TI__Guru 58861 points

Hi Michael Kruger,

Unfortunately I am still unable to really see the images. When I click on the links the images are very small, which is not ideal for interpreting logic analyzer plots

Can you either paste the image directly into the post (this usually allows us to click on them so they look bigger), or paste them into something like Excel / Word / PPT so we can manipulate the images?

-Bryan

0 Michael Kruger over 1 year ago in reply to Bryan Lizon86

Prodigy 10 points

Maybe these are more readable?

0 Bryan Lizon86 over 1 year ago in reply to Michael Kruger

TI__Guru 58861 points

Hi Michael Kruger,

Thanks, this finally worked.

To clarify, in all images, the blue/purple signal is DIN (to the ADC) and the yellow/green signal is DOUT (from the ADC), correct?

If I read all of the images left to right, top to bottom, this is what I see. Please address any comments I have made:

Send the START command
RREG for CONFIG2, DRDY is high, int CLK, SYNCOUT disabled, Pulse control mode
RREG for CONFIG2, DRDY is low, int CLK, SYNCOUT disabled, Pulse control mode
?? There is no valid command 0x32 - are you sure you are launching/capturing data on the right SCLK edge? DIN is latched into the ADC on the falling SCLK edge
RREG for CONFIG2, DRDY is low, int CLK, SYNCOUT disabled, Pulse control mode --> RDATA command, data = 0x3FE77F, checksum = 0x20
Wait for >3ms, then issue another START command
RREG for CONFIG2, DRDY is high, ext CLK, SYNCOUT disabled, Gate control mode --> why is the clock now external, and you are in gate control mode?
RREG for CONFIG2, DRDY is high, int CLK, SYNCOUT disabled, Pulse control mode
RREG for CONFIG2, DRDY is high, ext CLK, SYNCOUT disabled, Pulse control mode --> why is the clock external again?
RREG for CONFIG2, DRDY is low, int CLK, SYNCOUT disabled, Pulse control mode --> RDATA command, data = 0x3FE77F, checksum = 0x20

It seems like there is something messed up in your communication, because the settings seem to be changing without you actually doing anything (unless you are performing additional actions and just not capturing them here). Also, the checksum I calculate for 0x3FE77F is 0x40, not 0x20

Please make sure your controller is sending the data to DIN on the appropriate SCLK edge, and that your analyzer is capturing data from DOUT on the appropriate SCLK edge

-Bryan

0 Michael Kruger over 1 year ago in reply to Bryan Lizon86

Prodigy 10 points

Hi Bryan,

Yes, unfortunately I see we are having issues with the logic analyzer capturing the traces correctly. So I dont think the settings are changing at all. I will try to recapture it.

The original message has the communication as sent and received over SPI as our microcontroller interprets it:

0 Bryan Lizon86 over 1 year ago in reply to Michael Kruger

TI__Guru 58861 points

Hi Michael Kruger,

Thanks for clarifying

There is no clear reason why the ADC would read back the same data, unless of course the conversion didn't actually restart (though this is inconsistent with the DRDY behavior)

Can you probe the DRDY pin to see if this pin follows the same behavior as the DRDY bit in CONFIG2?
Can you try controlling conversions with the START pin instead of the START command to see if that changes the behavior?
What SCLK and CLK speeds are you are using?
I assume START is tied low, and RESET/PWDN are pulled high?
Is the next read after the duplicate always new data? You said this can happen "a few times in a row", so does that mean you can read the same value more than one additional time? Can you be more explicit about how often (does every read get repeated, just certain ones?) and how many repeated data there are?
Can you reproduce this issue on your end? It seems like you have gotten systems back from the field that have this issue, but have you had any luck reproducing it on a known good system in your lab for example?
Does this issue happen randomly, or is there any discernible pattern to it?

An alternative solution to this issue would be to just ignore identical data points during this stabilization period i.e. any time the difference = 0, something is wrong

-Bryan

0 Michael Kruger over 1 year ago in reply to Bryan Lizon86

Prodigy 10 points

Hi Bryan,

Thanks again for the reply and your suggestions.

Can you probe the DRDY pin to see if this pin follows the same behavior as the DRDY bit in CONFIG2?
- I will try to probe this.
Can you try controlling conversions with the START pin instead of the START command to see if that changes the behavior?
- Unfortunately we don't have a connection between the MCU and this pin.
What SCLK and CLK speeds are you are using?
- We are using an SPI clock speed of 200 kHz
I assume START is tied low, and RESET/PWDN are pulled high?
- Yes indeed.
Is the next read after the duplicate always new data? You said this can happen "a few times in a row", so does that mean you can read the same value more than one additional time? Can you be more explicit about how often (does every read get repeated, just certain ones?) and how many repeated data there are?
- Not always, sometimes we get the same value several times in a row. I cant be more explicit as its really random.
Can you reproduce this issue on your end? It seems like you have gotten systems back from the field that have this issue, but have you had any luck reproducing it on a known good system in your lab for example?
- We have been able to reproduce it but its very sporadic.
Does this issue happen randomly, or is there any discernible pattern to it?
- Its random.

Our solution is indeed to ignore identical data points and restart the measurement. This does delay our startup sequence, but we have applied other optimizations so this is no longer as big of an issue for us. So, for now we are parking this issue. I will resolve it for now.

Thanks again for your help.

Data converters

Data converters forum

ADS1259: ADC conversions returning duplicate values.