• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 45 subscribers
  • Views 496 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.

ADS122C04: RDATA command returns 40 bits instead of 24

Daniel Melendy
Prodigy 20 points
Part Number: ADS122C04

Hi All,  I'm having a problem with the ADS122C04 when I attempt to read back a conversion result.  Basically what I'm finding is that I have to read out 5 bytes instead of the 3 bytes I would expect for a 24-bit result.  If I only read 3 bytes after giving the RDATA command then my next result is corrupted because it contains the 2 "left-over" bytes.  I have found work-arounds but I would like to understand what is the source of the two extra bytes.  My conversion result is good as long as I always read out all five bytes and only use the first 3.  I know that there are some features on the part that can cause extra bytes to appear in the output (CRC, data-count, etc.) but I have all of those features turned off.

Here are my configuration register values:

Reg0 = 0x70, Reg1 = 0x20, Reg2 = 0x00, Reg3 = 0x00

Here is the sequence of commands that I'm giving the ADC:

1. RESET (0x06)

2. WREG (0x40, 0x44, 0x48, 0x4D)  This is as a single I2C frame that alternates between command and register data.

3. START (0x08), then wait for 100mS

4. RDATA (0x10), as command write and then a I2C read of the result

Thanks for any help you can provide.

  • 0
    TI__Guru** 113765 points
    Hi Daniel,

    Welcome to the E2E forum! I can assure you that the conversion result is only 24-bit, however if you have CRC enabled this would be an additional 16-bits. Do you have a scope or logic analyzer shot of the communication when using the RDATA command? The command sequence is shown in Figure 57 of the ADS122C04 datasheet on page 39.

    Are you using a bit-bang method for I2C or are you using a built-in micro I2C peripheral? I have seen issues where a micro has a FIFO that is not completely cleared, or if the device is read before the next set of SCL clocks are actually issued. From the description of the issue you are seeing, it appears that you are reading the buffer contents before the completion of the communication cycle (or CRC is inadvertently enabled).

    I would suggest reading the register contents to verify that registers were written correctly.

    Best regards,
    Bob B
  • 0 in reply to Bob Benjamin
    Prodigy 20 points
    Hi Bob, It turned out I had an error in my code and the CRC was actually turned on. I turned it off and now my result is the expected 3 bytes. Thanks for the help!