ADS7138: I2C Clock Stretching

Part Number: ADS7138

Hello,

I have a question about manual mode on the ADS7138 -- I'm finding the device doesn't work exactly like the datasheet describes.

For manual mode:

It says you should send a Start command, 7-bit slave address, the R bit, and then you'll get an ACK and then the clock stretching will begin.

On my device, I send the Start, ADDR, R bit, get the ACK, and then the device immediately spits out the last conversion.  After I receive the conversion results, then it initiates a clock stretching period.

I would expect that after the Start/ADDR/R/Ack the device would hold SCL low until the conversion is complete, then spit out the 2 byte result.  The result I'm getting seems correct based on external measurements of the voltage applied at the input of the A/D converter. (The device ADDR in the above screenshot is 0x17)

I'm thinking adjusting the code to read 4 bytes and see what it does -- if it waits for 2 more bytes before stopping the communication.  But is this expected operation of the device?

Also, it seems the I2C Controller I'm using does not deliver an ACK at the end of receiving the 2 bytes.  I'm not sure why - also not sure if that is related to the issue I'm seeing.

Thanks,

  • Hello,

    Overall, the device seems to be working well. I would suggest making sure the MANUAL_CHID field is programmed correctly.

    I would also suggest looking into the lack of ACK, the device expects this. Without, I would presume the device would not continue responding until the ACK is sent. 

    Regards

    Cynthia 

  • Ok, so I think I understand why it's sending a NACK -- that seems to be how the I2C Protocol is supposed to work after a read message.  It sends a NA then the stop command.

    For example, see here: https://github.com/torvalds/linux/blob/master/Documentation/i2c/i2c-protocol.rst

    For simple read message the format is:

    S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P

    I know the ADS7138 documentation shows that it should be an ACK instead -- seems odd and possibly violates the I2C Protocol?  For example see here where it is explained better:

    https://stackoverflow.com/questions/37040696/nack-and-ack-responses-on-i2c-bus

    "Within a transfer: after the side reading a byte (master on a receive or slave on a send) receives a byte, it must send an ACK. The major exception is if the receiver is controlling the number of bytes sent, it must send a NACK after the last byte to be sent. For example, on a slave-to-master transfer, the master must send a NACK just before sending a STOP condition to end the transfer. (This is required by the spec.)."

    So the ADS7138 according to my experience seems to not be working as advertised, but still is giving a correct result. I've verified the channel is correct as I've changed the input signal to known values and it's been correctly reading them.

  • Brett,

    Looking closer at your diagram. The SDA data does not seem to be driven correctly. Notice that the low states are quite a bit above ground, I cannot tell for sure what value, but there definitely seems to be an inconsistency. The low and high state values are defined by DVDD. Notice toward the end of the communication there is a level change for the low state. 
    I suggest looking at your connection here and making sure it is driven correctly. 

    Regards

    Cynthia