• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 45 subscribers
  • Views 294 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.

ADS114S08: ADS114S08 randomly data corruption

Yui Sakazume
Prodigy 30 points
Part Number: ADS114S08


I am using ADS114S08 for current measurement but it causes data corruption randomly.

Device configuration overview:
- Internal 4MHz OSC
- Data format is data with CRC
- Single ended
- PGA is disabled
- Data Rate is 2000

I want to switch and measure input channels in sequence using read-direct mode. So, I send following command and read data at the same time.(NEXT_CH is incremented each time and wraparounded if it reaches to last channel.)
0x42, 0x01, (NEXT_CH<<4 + 0xc), 0x0
All received data will be CRC checked but CRC error is reported sometimes. Frequency is several % probably.
The ADC connect to micro computer board with SPI but DRDY has not connected to reduce number of wireing. Instead of DRDY monitoring, enough wait is applied (656usec or more).

I guessing it is some timing issue because the same issue is not seen if RDATA command is used but it is not solved even if conversion wait is extended. Is there a known issue or something idea to solve the issue?

  • 0
    TI__Guru** 113765 points

    Hi Yui Sakazume,

    I'm a little confused by your command sequence as you are transmitting 4 bytes where the PGA register is always fixed.  Are you also enabling the STATUS byte?

    If by using RDATA the issue is resolved, then most likely the issue is timing related to the use of the timer instead of monitoring DRDY.  Using the RDATA command blocks transfer of incoming conversion results to the output buffer until all conversion data are read.  When using the read data direct, you must completely read out the conversion result before the end of the next conversion or data corruption can occur and disrupt the computation of the CRC result.

    How the timing issue can happen is the internal clock compared to the micro timer can drift over time.  The 656.3us conversion period assumes a precise oscillator of 4.096MHz (but the specification for the device is +/- 1.5%).  Also there is some additional delay depending on the mux delay setting.  The default delay for the mux delay setting is an additional 54.7us.  So assuming a precise clock, the delay time would be 656.3us + 54.7us = 711us following the mux write decode.  As the clocks can drift, the level of precision changes and you can hit a small window where the next conversion data result can disrupt the read from the output buffer.

    If you cannot use the dedicated DRDY pin, I would suggest having the micro monitor the DOUT/DRDY pin to improve the timing to make sure you are reading back the conversion data within the correct time frame.  To use this method when polling the pin requires that you force DOUT/DRDY high from a register read and then monitor the pin for a high to low transition.  If you have a spare GPIO pin you can tie the DOUT/DRDY to both the SDI for the micro and also the GPIO.  Then enable an interrupt for the GPIO looking for a high to low transition to start the conversion result read.

    If that is not possible, then I would suggest either using single-shot mode or use the RDATA command.  If you use single-shot mode, then you can substitute the START command in the communication sequence. This would now become 0x42, 0x00, (NEXT_CH<<4 + 0xc), 0x08 (START command).

    If you are still having issues I would suggest using a logic analyzer to capture the communication to help determine why you are having issues.  You need to make sure that the micro code is capturing the data correctly as well as computing the CRC result correctly.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 30 points

    Hi Bob,

    Thanks for the reply.
    Sorry, My explanation is wrong. Please let me correct the description.
    STATUS byte is not used and WREG command is 0x42, 0x01, (NEXT_CH<<4 + 0xc), 3 byte transfer is used.

    Also, I noticed 2nd byte of WREG command is wrong.
    Accoring to the datasheet.
    'The second command byte is the number of registers to write (minus 1):'
    So, it should be 0x0. I fixed it and tried yesterday but the issue is not solved.

    I already tried to extend the wait time to 10 times or more but the issue was not resolved.

    The communication procedure is as follows, is this basically correct?
    1. Set CS to Low
    2. Wait 711us or more
    3. Send WREG command and receive data at the same time
    4. Set CS to High

    When a CRC error is reported, the data bytes seem to start at 0xFF, 0x00 in mostly case. It might be clue.

    Regards,

    Yui

  • 0 in reply to Yui Sakazume
    TI__Guru** 113765 points

    Hi Yui,

    The 3 byte transfer and data capture would be correct for the use case.  As far as your sequence I would alter to:

    1. Set CS to Low
    2. Send WREG command and receive data at the same time
    3. Set CS to High
    4. Wait 711us or more

    Any spurious noise on the SCLK will cause an issue if the noise is strong enough to appear as an extraneous clock.  What SCLK frequency are you using?

    If you are still having issues I would highly recommend collecting data on a logic analyzer so we can see what is actually happening when the error in communication takes place.  Or you can follow my previous recommendations.

    Best regards,

    Bob B