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.

ADS1258: Stability issues running in continuous conversion mode

Part Number: ADS1258
Other Parts Discussed in Thread: TMP235,

We have data acquisition boards each running 9 x ADS1258 in continuous conversion mode across 16 channels.

Our boards performed without issue for a few weeks running 24x7 at slightly elevated temperatures (50C) measured on the board using a TMP235 (internal temperature registers not tracked). One master ADS1258 per board runs an oscillator, the others take a clock signal from the master.

Our boards have become gradually less reliable. They refuse to initialise (SPI setting registers) unless they have been powered off for a few minutes. During running, from minutes to hours after power on, various ADS1258 fail to before others (not producing DRDY signals) until the master ADS1258 falls and the whole board fails to produce DRDY or respond to SPI.

Initially this seemed to be a temperature dependant issue but even running the boards at 20C in a climatic chamber, we are still seeing the issues.

Are there any known reliability issues of which we should be aware? Should we be using the ADS1258-EP instead?

We had of course initially assumed that the issue was with the power supply (each chip has an independent LDO providing clean power) or a manufacturing issue with our boards. However the issue is shared across boards and across various ADS1258 components so we are now starting to suspect these components.

Any insight would be appreciated - thanks.

  • Hi Gary,

    To be clear, you are using a 32kHz crystal on one ADS1258, and then feeding the CLKIO signal from that single device to the CLKIO pin on 8x additional ADS1258s on your board - correct?

    How does the clock signal from the master fan out to the rest of the ADCs? Is there a symmetric clock signal path to each device?

    -Bryan

  • Hi Bryan,

    Thank you for your prompt response. Yes we have a 32kHz crystal on each ADS1258 but only one (the middle one) is connected. The rest are connected to the CLKIO signal from middle ADS1258 in our chain.

    We can change the configuration so that an ADS1258 drives the shared clock line if you think this would be more reliable?

    I attach a picture of the shared CLKIO line for reference.

    Thanks again for your help.

    Gary.

  • Hi Gary,

    Thanks for the additional information. Let me ask one clarifying question: you say that there is a crystal on each ADC, but only one ADC actually has the crystal connected (let's call it ADC1). Then, the clock output signal from the CLKIO pin on ADC1 is connected to the other 8x ADCs, and this is how they all get their master clock signal. However, your statement about modifying the configuration such that the ADS1258 drives the shared clock line confused me a bit - is this not what you are already doing? Isn't ADC1 driving the clock inputs on all the other 8x ADCs? So I am not sure what you would change here, but maybe I missed something in your explanation.

    I will say that there are many e2e threads concerning getting the watch crystals to oscillate, both initially at startup and then reliably after that. I surmise this could be the issue, and our general recommendation would be to use a discrete clock oscillator instead of a crystal. Fortunately, it seems like you already have all of the CLKIO lines connected together, so it might be possible to substitute an oscillator with the crystal. I leave it to you to determine if this is feasible for your system.

    I am also not sure about the drive strength of the CLKIO output from the ADS1258. I have not seen the configuration you have being used by other engineers, so I cannot definitively tell you it is acceptable. I can discuss internally with our design team, but it might take a few days to get an answer (just to level-set expectations). There could also be noise or some other disturbance on this longer trace that disrupts the clock signals at random times. With an intermittent clock signal, the ADC could enter an unknown state that can only be recovered via a power cycle

    Also, switching to the ADS1258-EP would not solve any of these issues. I know you had asked about this in your original post.

    -Bryan

  • Hi Bryan,

    Thank you for the insight. We can probably patch an oscillator into the circuit quite easily so will give this a go. Otherwise I would still be interested to know if it was acceptable to use the CLKIO output to drive other ADS1258; we chose this configuration because it allows us to synchronise all of the ADCs (to avoid SPI bus clashes) without an external oscillator.

    Just to clarify on the way we can "configure" this behaviour: the crystals are wired through 0R links so we can reconfigure the board if necessary and we have a similar optional resistor to pull CLKSEL high/low. This means that we could drive the oscillator at ADC0 at one end and share it to ADC1 through ADC8 rather than at ADC4 as at present (shared to ADC0-3 and ADC5-8) but this is not something we can change in software. My query was whether this might be a more reliable signal path.

    Good to know not to switch out all our components to ADS1258-EP just yet as we have a reasonable stock of the ADS1258!

    Cheers,

    Gary.

  • Hi Gary,

    I can take a look into the CLKIO drive strength question, but as I said I will need a few days. I would expect a response at the beginning of next week for this specific question.

    Thanks for clarifying about the way the clock signals can be configured. I would have guessed that of the possible configurations, having the ADC in the center would be the most reliable. You could check other configurations, but then you are only adding to the clock trace length in one direction or another. However, if you did perform this experiment and the failures increased in frequency, you could more definitively conclude that the clock signals are the culprit.

    I will let you know what I discover from the design team. If you have any new results from your tests, please let me know.

    -Bryan

  • Hi Gary,

    We discussed this topic internally, it seems that your use case is reasonable for the ADS1258. However, there was not a definitive answer regarding your specific situation as the performance depends on the signal path layout and routing that in turn impacts the trace impedance (matching). It might be necessary to add a clock buffer at the output of the main ADC, but I would have to defer to TI's clock and timing team for a a more definitive answer to that question: https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum

    They should also be able to help with a suitable clock oscillator if that is required.

    Let me know if you have any more details to share on the outcome of any experiments you may have tried.

    -Bryan

  • Hi Bryan,

    Thank you for following up on this.

    We have replaced the crystal on one of our boards for an external oscillator and this definitely improves the start up issues we have been having. The existing crystal was taking ~150ms to generate a clean CLKIO output and was a bit noisy as it ramped up, causing other ADCs to fail to start up correctly unless it had been powered down for a few minutes first.

    Unfortunately this hasn't helped our stability issue during continuous conversion. We are still seeing ADS1258s stop responding to SPI randomly as they are left running for a few hours. I reiterate that when the boards were first made, they ran for weeks without issue. This behaviour is not measurably better than when generating the clock signal from one ADS1258 - we have one board running in the same rack using the old configuration that is behaving reliably on the bench.

    Can you think of any degradation issues with these devices (or elsewhere) that we could be seeing? It is typically the same ADS1258 devices that fail first before they all finally give up.

    Gary.

  • Hi Gary,

    Have you tried replacing the devices that are failing more often with new devices? Or performing any type of A-B-A swap to see if the failure follows the device or the location? Given the clocking scheme it is certainly possible that layout issues are causing problems.

    Another thing to try might be to enable all of the crystals on each device and remove the CLKIO connections between parts and see if that makes a difference. If the issues persist, this might rule out some of the layout concerns.

    Also, is there any way to reset the devices once this issued is recovered? Can you toggle the RESET pin or issue the RESET command, or do you need to power cycle the ADC in order to recover?

    -Bryan

  • Hi Bryan,

    Thank you for these ideas - we started with the last as it was the easiest to test.

    We have patched in some circuitry to the RESET pin in order to try recovering without a power cycle. Up until now the RESET pin has not been connected.

    Now we are forcing RESET high (or low, to reset) and have discovered that the device now appears to be more stable. We need to do more testing to be sure, but do you think a floating RESET could have caused the instability we're seeing?

    Gary.

  • Hi Gary

    This is certainly possible. If the pin is floating then it will not be in a known state. Noise (digital, clock, etc.) could certainly cause this pin voltage to drop below the low threshold, forcing a RESET. You can always tie this pin to DVDD through a weak pull-up if you do not want to control it via a GPIO.

    -Bryan

  • Hi Bryan,

    Thanks for your help with this issue. The devices are stable now RESET is held high and we're reliably able to restart them now we're using an external oscillator.

    Gary.

  • Hi Gary,

    Glad to hear this was resolved, and was a (relatively) easy fix.

    If you have additional questions about the ADS1258, please start a new thread and we will be happy to provide support

    -Bryan