• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 709 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.

F28M35 ADC results appear to have stuck bits

Mitch Hanks
Intellectual 670 points

I have observed when running my software that the results of an ADC conversion appear to have stuck bits.  I get results that always have 'A' or 'C' in the middle four bits of the result and the lower four bits only change in the 0th and 1st bit positions.  For example, if I run a sawtooth waveform into the ADC input, let the ADC sample the waveform, and then plot the results, I see a staircase instead of a smooth ramp.  I'll see values such as:  0x4A5, 0x4A4, 0x4A4, 0x5A4, 0x5A4, 0x5A5, 0x6A4, 0x6A4, 0x6A4 and so forth.  I am unable to easily inject signals into the ADC1 so these results are from the ADC2.  

In order to ensure that it isn't my code, I modified the adc_soc_c28  example by simply replicating ADC2 functionality wherever there is ADC1 functionality and setting up the right channels and triggers for my two inputs that I can test.  Running this code and injecting an analog test signal I see similar results.   It appears that the code has the ADC related errata fixes.  Any idea what might be going on?  

Mitch

  • 0
    TI__Guru 60865 points

    Hi Mitch,

    The behavior is definitely strange and unexpected (not what we would expect to see from the first sample issue or the 14th cycle erratum).

    My first guess is that something is wrong with the ADC clocking.  You may want to measure the input clock frequency, check the PLL settings, and then enable XCLKOUT to check the PLL output frequency.  Once you have verified the SYSCLK frequency, verify the ACIB clock dividers (which also clock the ADC).  

    You can also check if the ADC has been damaged by ESD/EOS by checking if the leakage into any ADC input is > 2uA.

    Is this on a TI EVM or on a custom application board? In either case (but especially for a custom board) it is probably a good idea to check the VDDA voltage.  You can also check the VREFHI voltage if using external reference.  

  • 0 in reply to Devin Cottier
    Intellectual 670 points

    It was the VDDA voltage which was capacitively coupled to ground but not connected to 3.3v.  Thanks for the tip!

    Mitch