Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 45 subscribers
  • Views 193 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ADS1219: I2C communication issues when polling status while ADC is converting

Ralph Kondziella
Prodigy 10 points
Part Number: ADS1219

It is about two ADS1219 connected to the same I2C Bus, when in single acquisition mode, the ADC is disturbing the I2C Communication, so it is impossible to poll the status.

The Addresses as wired are ADC1: A0=1, A1=0 and ADC2: A0=0, A1=0

The failure occurs after starting a single conversion and trying to read register 0x24 to get the
DRDY state.

What happens:
While converting the ADS1219 sporadically pulls the SDA low.
The Pull-Up resistors for SDA and SCL are 1k each, we tried 500Ohm and still had the same issue.

  • 0
    TI__Guru** 113765 points

    Hi Ralph,

    Welcome to the E2E forum!  The SDA line should only go low if the ADS1219 is addressed and either ACK or sending data.  I have seen issues where repeated polling of the register 1 can sometimes happen quicker in a main polling loop than the peripheral can actually transmit and receive the data.  This would be similar to queueing commands for the I2C peripheral faster than the peripheral can complete the actions.  The end result is multiple commands are in the queue that are not yet completed.  So you need to ensure that you are receiving the appropriate ACK when addressing the device and that the device has time to return the data before queueing the next request for the register read.

    One way to help the process go smoother is to start the conversion, wait a predetermined time (the data rate period) and then poll the register.

    Do you have oscilloscope shots or better yet, logic analyzer shots of the communication?  This will help to determine what is going on at the time SDA is going low.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 10 points

    Yes, we have oscilloscope shots:

  • 0 in reply to Ralph Kondziella
    TI__Guru** 113765 points

    Hi Ralph,

    I'm confused at this point.  Originally you said that the SDA was sporadically pulling SDA low, but the scope shots show that the device issued NACK instead of ACK when the RREG command was sent.  This means that when SDA is expected to go low it does not.

    There are a number of possible reasons for a NACK.  Most common would be noise on the bus if this is a prototyping situation with fly-wire connections.  Another possible issue could be that you are attempting to read from the ADS1219 at the same time there is a register update internal to the device.

    In any case your code needs to be able to handle a NACK condition.  When you receive a NACK from the ADS1219, you need to have an error handling routine.  This could simply be to retry the entire transmission for an allotted number of attempts.

    If you NACK on a command, then an attempt to immediately read from the device as if the command was accepted properly, the result will be invalid.  So it is unclear to me the processing of events taking place and how a NACK condition is handled.

    Best regards,

    Bob B