• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 1337 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.

RM42L432: ADC input spiking

David Fleissner
Prodigy 110 points
Part Number: RM42L432

Hello,

We’re working with the RM42L432 in a new product and we’ve seen some weird behavior with the ADC inputs. We found that when reading ADIN[0..3, 20] as part of a group conversion, the group conversion creates a ~5ns spike (almost as if the pin is briefly shorted to ground) on the first signal measured. This results in the ADC periodically measuring the voltage incorrectly. The fix we found was to disable measurement of ADIN[20], which is the only input directly connected to ground. Is it problematic to connect one of the ADC pins directly to GND/VDD? Or, does this sound like a symptom of not allowing enough switching time between inputs? We’re fine with our workaround, we’d just like to understand what is causing the problem in case we are using the ADC inputs incorrectly.

One thought we had was that this could be caused by the sample capacitor in the ADC recharging after being grounded. I'm not so sure about this though because I would expect to see similar (although smaller) behavior on the other inputs as well since none of the ADC inputs are at the same voltage. I also tried adding a 1nF capacitor to the ADC input and while it reduced the spiking behavior, it didn't help as much as I would expect if this was caused by the 8pF capacitor.

ADC settings:
- 12-bit mode
- 10Mhz ADC clock
- Sampling time ~700ns
- ADIN[0..3, 20] are part of Group 1 conversion
- Sequential channel conversion

  • 0
    TI__Guru 59540 points
    Hello David,

    Apologies for the delayed response. Do you have a scope plot of the behavior you can post? What is the magnitude of the glitch that you are seeing? Does it correlate to any of the other voltage levels prior to the conversion on channel 20 or whichever channel is seeing the spike?

    In general, I am not aware of any limitations of connecting directly to GND or VCC so this shouldn't result in an issue that I am aware of.

    I am also going to forward your description to one of our ADC experts to see if they have any insights as to what might cause this behavior.

    Here are a couple of application notes that you may want to take a look at to see if they add any insight.

    www.ti.com/.../spna118b.pdf

    www.ti.com/.../spna140.pdf
  • 0 in reply to Chuck Davenport
    Prodigy 110 points

    Here's a scope capture of the glitch on ADIN[0] and some more relevant information. The glitch is about 7-8 ns long and the voltage drops ~1V. The glitch on ADIN[0] goes away once we disable conversion on ADIN[20]. If we disable conversion on ADIN[0], the glitch on ADIN[0] goes away and an identical glitch appears on ADIN[1].

    ADC Input Voltage Source
    ADIN[0] 3.02V Op amp output

    ADIN[1]

    		 2.50V Op amp output
    ADIN[2] 2.17V Op amp output
    ADIN[3] 2.00V 10k resistor
    ADIN[20] 0V Direct GND connection

  • 0 in reply to David Fleissner
    TI__Guru 59540 points
    Thanks. I will forward this to our ADC expert for his input on this. Can you forward your ADC setup information as well? i.e., give a register dump for the ADC so we can review the settings. You should be able to do this with CCS and a memory export.
  • 0 in reply to David Fleissner
    TI__Guru 59540 points
    Hi David,

    Sorry for the long delay in getting back to you. I finally was able to reach our ADC expert and he provided the following explanation/details.

    There is no overlap in mux switches causing dip in voltage. Although it is unusual to perform a conversion on a grounded ADIN, it is perfectly OK to connect an ADIN pin to GND.

    In the described [0, 1, 2, 3, 20] conversion sequence, I fully expect a glitch as shown when switching previously grounded mux and sampling caps to 3 V. The glitch is so narrow(5-7 nsec) there should be no conversion inaccuracy with 700 nsec sampling time. The 5-7 nsec glitch doesn’t improve with external 1 nF because 5-7 nsec is governed by mux + samp cap and mux on-resistance time constant.

    Bottom line is glitch is normal and poses no concerns as long as minimum specified sampling times are maintained."

    Let me know if there are further questions.
  • 0 in reply to Chuck Davenport
    Prodigy 110 points

    The problem is we were seeing inaccurate ADC conversions periodically. Every few hundred conversions or so on ADIN[0] we would get a conversion that was a few hundred counts lower than expected. I then looked at the input on a scope and saw the glitch, and I assumed it was related. Both the glitch and the inaccurate conversion issue went away when we stopped sampling ADIN[20]. I can't help but think the two are related, but I may be wrong. Maybe we just needed a longer conversion time?

  • 0 in reply to David Fleissner
    TI__Guru 59540 points
    Hi David,

    It is difficult to argue with your observations. Sometimes the empirical results are more powerful than theoretical understanding so I also would be inclined to believe there is some connection here; however, it seems this is difficult to prove.

    If we proceed with the understanding that there is some influence even if only periodically as you have mentioned, is there a reason for performing a conversion on a grounded ADIN pin? If grounded, wouldn't you know it is always going to return 0 or something very close to that? Is this some sort of ground reference test for safety?

    If this glitch is a result of some sort of Csamp settling/charging time then slowing the conversion time could help to reduce or eliminate it. This is, of course, if your application can deal with the slower sample and conversion times.