• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 434 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.

MSP430F5510 and ADC10 ramdom data errors

Richard Bissen
Prodigy 20 points


I had developed code that samples ADC data using timer trigger and the DMA controller writing data to a buffer. This all works great with one exception; I will get incorrect data (0x0FF or 0x300). I setup the trigger to sample every 8ms in the pulse sample mode. I would have never noticed the issue except we should never get this value with the input we are supplying. When it fails it is always the same data pattern (0x0FF or 0x300). I also tried 8bit conversion but the data is 0x3F or 0xC0.

I am using MODOSC at 5MHz and the ADC10SHT_2 and ADC10DIV_0. I have also checked for other errors (ADC10TOVIFG and ADC10OVIFG) but this never occurs. The failure rate is only ~8 in a 24 hour period but this data is used for ECG and is unacceptable.

Any input would be appreciated.

  • 0
    Guru 227245 points

    So you're getting a value of 1/4 Vref or 3/4 Vref once in a while. That's strange.
    It's possible that the input data is just that way sometimes (spikes). The ADC10/12 takes 'snapshots' from the input signal. And if there are spikes, chances are that it will capture at the moment of a spike. However, scanning a 3h log of independently sampled analog data (digital scope stream) for a single short anomaly is next to impossible.
    It's also possible that you have a problem in your code (but unlikely, considering the failure rate of 1:1.350.000)
    Of course there is always a chance for a yet undetected silcon bug too.

    Since it is always the same pattern, the pragmatic approach would be to just look for this pattern and repeat the conversion. I guess anything else is beyond this forum and requires one of the TI engineers to look at it.

  • 0 in reply to Jens-Michael Gross
    Prodigy 20 points

    I have done some testing with the ADC10 conversion and have determined the problem occurs when the input voltage results in the boundary between 0x200 and 0x1FF. I setup a test with the input voltage of 1.25v (our VREF is 2.5v). I did back-to-back reads and I got a 25% failure rate when reading the value from ADC10MEM0. The value would be 0x300 or 0x0FF. If I added a delay (1ms) between reads the failure rate drop way down (was more like the previous errors I was getting before). I raised or lowered the input voltage and the data conversion was never in error of the expected value. So at this point I am concluding the issue is in doing a conversion where the transition results in a value between the lower and upper (data bit 9) sections.

     

  • 0 in reply to Richard Bissen
    Guru 227245 points

    Richard Bissen said:
    have determined the problem occurs when the input voltage results in the boundary between 0x200 and 0x1FF.

    From the workings of the ADC, as far as I know them, this gives me two possible reasons. Either the voltage on the sampling capacitor drops during the conversion, which will make the conversion process enter the "wrong branch of the digital tree", or the reference voltage changes, with the same effect but inverted result.

    The first will happen if the conversion frequency is too low, the second if it is too fast.
    In the second case, it might be necessary to enable the reference output adn externally buffer the reference voltage with a 100nF ceramic/10µF tantalum capacitor. Maybe it also helps to enable the reference buffer etc. In the first case, the solution is obvious.

**Attention** This is a public forum