• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 333 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.

ADS7924: ADS7924 I²C Read Causes Glitches and Sudden Jumps in ADC Data

sw w
Prodigy 70 points
Part Number: ADS7924
Other Parts Discussed in Thread: OPA325, ADC121C027

Tool/software:

I am using I²C at 100kHz to read ADC data. There are two ADC chips on the I²C bus: one is ADS121C, and the other is ADS7924.

I am reading data from both ADCs in a loop running at 1kHz. The data from ADS121C is stable and within the expected range, even when there are minor fluctuations.

However, the data from ADS7924 shows glitches and abnormal jumps on all channels. For example, the normal value might be 2500, but it occasionally jumps by powers of two — like increasing by 2048 to 4548, decreasing by 2048 to 452, or jumping by ±1024, ±512, ±128, ±64, ±8, etc.

green data is 121C, blue data is 7924.

I have checked the I²C waveform on an oscilloscope and found no obvious issues. However, the data captured by a logic analyzer confirms that the raw values returned by the ADS7924 are incorrect during those jumps.

What could be the cause of this? Is there something I might be missing in the read process for ADS7924?

Thank you!

  • 0
    TI__Guru**** 180831 points

    Hi sw w,

    Can you provide a schematic showing your connections with the two ADC's?  Can you also provide details on how you have the ADS7924 registers configured?

  • 0 in reply to Tom Hendrick
    Prodigy 70 points

    Hi tom,


    ADS7924's mode registers is " Auto-Scan mode", and i tryed  " Auto-Single mode" it also has this problem. Below is the abnormal data in "Auto-Scan mode" captured by the logic analyzer(I just read two channels).



    The schematic I used was based on the ADS7924 evaluation board. I’ve also previously asked questions related to the evaluation board(https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1492012/ads7924-stm32-iic-read-register-no-ack).

    Additionally, there is no issue with our sensor data itself, as reading it with other ADC chips does not show any abnormal fluctuations.

  • 0 in reply to sw w
    TI__Guru**** 180831 points

    Could the issue be related to the floating RESET pin?  Please add a pull-up or tie that pin to AVDD5V and see if that resolves your issue.

  • 0 in reply to Tom Hendrick
    Prodigy 70 points

    Hi, tom
    sorry, I previously sent the schematic of the previous version. This is the latest one. Could you check if there’s any issue?


    I saw you mentioned that the RESET pin needs to be connected to VDD5V. Currently, we have it connected to VDD3V — could this be a possible cause of the issue?

  • 0 in reply to sw w
    TI__Guru**** 180831 points

    Hi sw w,

    The pull-up to 3.3 on RESET is fine.  Can you put an o'scope on the input to the OPA325 and compare that to the input pin (pin 14) of the ADS7924?

  • 0 in reply to Tom Hendrick
    Prodigy 70 points

    I forgot to mention that I encountered the same issue when reading through the 7924 evaluation board. I connected the oscilloscope to the BUFIN and BUFOUT pins on the evaluation board, as shown below.


    At the same time, I connected the logic analyzer to the SCL and SDA lines. Additionally, I added a GPIO pin to capture the waveform when an error occurs. The waveforms from both the oscilloscope and the logic analyzer at the same moment are shown below. My logic analyzer is sampling at 200 MHz, which is more than sufficient for the 100 kHz I²C speed.


  • 0 in reply to sw w
    TI__Guru**** 180831 points

    sw w,

    I recall the previous conversation.  Are you working with your own custome PCB now or still fly-wired ADS7924EVM?  The o'scope screen shot above is looking very noisey, which may be the root of your problem.  Are the red and blue traces the SDA and SCL lines?

  • 0 in reply to Tom Hendrick
    Prodigy 70 points

    Hi tom,

    The reason I used the evaluation board for testing is because it exhibits similar issues and is easier to solder wires onto. On our own board, it's quite difficult to access test points for measurement.

    Regarding your comment about noise possibly being introduced by flying wires — I agree with that. However, on our own circuit board, there are no flying wires, yet we still observe fluctuations in the readout.

    Lastly, the red and blue lines shown above correspond to the test points you suggested, i.e., BUFIN and BUFOUT highlighted by the red box in the first image of the 7924 evaluation board. The lower waveforms from the logic analyzer are from the SDA and SCL lines.

    So based on this, do you still believe the issue is more likely due to hardware interference, rather than a software problem (such as I²C configuration or 7924 settings)?

  • 0 in reply to sw w
    TI__Guru**** 180831 points

    Ah..OK then.  Are you actually probing the two test points on the EVM then and not your board?  I was interested to see the difference from BUFOUT ro the other side of your 1.5Kohm and 0.1uF cap.  From your original plot, is it same to assume this the conversion result of a single input channel?

    Notice how there are distince 'levels' of spike as the voltage collapses?  It looks to me like these are at code boundry points which is why I wanted to see the AIN pin versus BUF out.  I'm curious to see how well the LP Filter you have is working.  Where does that switching noise you see on the red and blue traces come from? 

  • 0 in reply to Tom Hendrick
    Prodigy 70 points

    yes, the probing on the EVM board. 

    I'm now using a better oscilloscope probe, and I have shorted pins 1 and 2 of J1 on the EVM using a jumper cap, and similarly, pins 3 and 4 are also shorted (since I'm only using CH0 and CH1).

    The waveforms of BUFIN and BUFOUT are shown below.

    • The first image shows the voltage in an idle state.

    • The second image shows the waveform when I manually disturb the sensor using a magnet to induce data fluctuation.

    • The lower image is the raw data graph collected by my MCU for the two channels.

    From the hardware waveforms, everything seems fine. This TI 7924 has been on the market for so many years, and the EVM itself should be reliable. But the IIC waveform data it outputs is indeed problematic.

    Although we can apply filters like low-pass filters or median filters to suppress some glitches, we are still aiming for cleaner raw data and are particularly interested in identifying the root cause behind the problem.
    Right now I have absolutely no idea where the problem lies. Argh...

  • 0 in reply to sw w
    TI__Guru**** 180831 points

    So, where is the ground reference in the o'scope plots?  You have basically a square wave by the looks of it on the analog input - have you tried putting in a DC signal like the one you have on the ADC121C027 and compare the results?

  • +1 in reply to Tom Hendrick
    Prodigy 70 points

    GND used TP3(AGND).

    We have tested our own 121C sensor, which also uses DC input, and it works fine.

    However, when I connected a clean 3.3V and 2.5V DC signal (from the EVM board) directly to CH2 and CH3, there were still noticeable data fluctuations.



    I re-tested the modes just now. When I switched from Auto-Scan mode to Manual-Scan mode, the glitches were gone. Could you please explain why this happens?





    I have another question. Since TI suggests sending additional commands to pause this mode before reading data, then what's the difference between this mode and the manual scan mode? 

    We chose the auto scan mode because we wanted to be able to directly read the data registers at any time without sending extra commands each time.

  • 0 in reply to sw w
    TI__Guru**** 180831 points

    Hi sw w,

    I did not realize that you were not exiting auto-scan mode before reading data.  This mode of operation is meant to be used as a system monitor in conjunction with the individually programmable alarm thresholds.  Basically, an autonomous feature that flags an interrupt if any conversion result exceeds the high or low limit that you pre-program. You can also program an alarm counter (up to 7 times) to reduce the chance of 'false alarms'.  Once an alarm occurs, you would stop the auto-scan mode and read the registers to see what channel caused the error.  Since there is no way to be sure what state the internal conversion process is in during auto-scan mode, the recommendation is to exit the mode before retrieving data.

    The manual scan mode lets you start conversions one each channel and then read all data once 'Data Ready' is set - that would trigger an interrupt to the MCU to let you know that you can retrieve the conversion results.