• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 191 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.

ADS7128: Trouble sending and receiving frames - datasheet error?

Mark Jarvis
Prodigy 10 points
Part Number: ADS7128

Is there another part in the TI family with a datasheet that goes into more detail regarding more specifics on the i2c communication with this device?  Specifically, where can I find more specific detail on what are called frames?

I have the May 2020 version of the datasheet, downloaded just a couple of days ago.  The parts I'm working with are not exactly behaving in accordance with the datasheet.   I'm using the OpenCores I2C controller IP in an FPGA implementation.

Section 8.3.10 Output Data Format, Figure 25. Data Frames for Reading Data, frame A: Reading ADC data.  The I2C transaction to read just one sample seems to indicate that, after reading the second byte, the host should generate an ACK. (and presumably, a STOP) condition.  For a read of just one ADC sample, prior to the host sending the STOP, the host should NACK the last byte, then STOP.  If the last byte of the ADC sample is ACK'd, subsequent I2C transactions are garbled.  This behavior is consistent with many other I2C devices (TI and others).  On a multi-byte read, the host does not ACK the last byte.

Section 8.4.1 Device Power-Up and Reset "The device can be reset by an I2C general call (00h) followed by a software reset (06h), by setting the RST bit, or..."  Is the detailed timing of this given anywhere, such as the datasheet of another TI device?  The sequence I came up with was:

S [device i2c addr] [write bit=0] <ACK from device> [00b] <ACK from device> [00b] <ACK from device> P

It doesn't work.  I can reset by writing the RST bit in register 1, but the above sequence doesn't seem to work.  Do I need a restart between the two bytes?

Section 8.5.1.1 Single Register Read, Figure 34. Reading Register Data.  The diagram suggests that, after sending the register address and getting an ACK from the ADS7128, the host (could? should?) send a STOP/RESTART, then START.  The only way I could get it to work was a single RESTART at that point.  A STOP won't work, and I doubt 2 consecutive START conditions will, either.  Also, as in the case above, the host should not ACK the last byte before the STOP condition.  Again, subsequent I2C transactions are garbled.

I know this is a lot, but I tried to soften it a bit by offering tips for others using this device.  Thanks

-Mark

  • 0
    Prodigy 10 points

    Correction: the reset sequences I tried are these:

    S [device i2c addr] [write bit=0] <ACK from device> [00b] <ACK from device> [06b] <ACK from device> P

    S [device i2c addr] [write bit=0] <ACK from device> [00b] <ACK from device>  Sr [device i2c addr] [write bit=0] <ACK from device>[06b] <ACK from device> P

    Neither had the equivalent effect of writing 1 to the RST bit.

    -Mark

  • 0 in reply to Mark Jarvis
    TI__Mastermind 24940 points

    Hello,

    And I2C frame is a standard name used in the I2C protocol to refer to a group of data bits being transferred across the bus separated by the start stop commands, buts does not include the start/stop commands, 

     Lets try to address each matter separately

    1. I do not understand this. Would you connect scope probes to the digital bus and capture the communications in question. This will help debugging.
    2. The following is the flow for sending a general call reset. Note that this communication will apply for all device on the I2C bus who acknowledge the call, not just the ADS7128.

    General Call, (0000 0000), sending 0000 0110 (06h) followed by a 0

    1. The device has been proven to work with either a Repeat Start, or a stop start command. I suggest using a scope probe connected to the I2C bust to confirm the communications

    Regards

    Cynthia