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.

ADC example bug?

Other Parts Discussed in Thread: CC3200

Hello, 

Doing all examples i found some bug in execution. When i run this example i noticed, that when i read any of the ADC pins for the first time it reads the voltage i apply right, but if in the same session i change the voltage input and read the values on the same pin, it will show me the read values from the previous measurement, and as much as i change it it will always show same values until i recompile it and start it again.

For example: for 1.46V it shows 4096, then 1.46 change -> 0V and it still shows 4096

What can it be and how can i fix it?

  • Hi Sergii,

    In this example's documentation, it states the following:-

    Input Amplitude - Low Level should be greater than 5 mV and high level should be less than 1.45 V.

    So 0V will do nothing, hence the reason you are seeing no change, you will need higher than 5mV to display a low level.

    Glenn.

  • i just gave an example, i tried changing from 1.46V -> 1V -> 0.7V ->0.5V -> 0V The values for all measurements are the same

  • Hi Sergii,

    What are your using to generate your signal? What sort of signal are you generating?

    The documentation specifies the following requirements:-

    Setup of signal genearator for generating analog signal:
    • Waveform - Select any suitable waveform - Sine,square,Ramp
    • Input Frequency - As ADC reaches nyquist rate at 31250 Hz, Input frequency should be between 50 Hz-30 KHz.
    • Input Amplitude - Low Level should be greater than 5 mV and high level should be less than 1.45 V.
    • Note - If there is a setting in the signal/function generator the change the output termination impedance of
    signal/Function generator to Infinite/High Z

    Glenn.

  • till now i've tried only DC inputs, from a regulated power supply.

  • I have not looked into the ADC example, but the documentation is quite specific in its requirements, and a DC current you are providing is quite different to the signal that is specified.

    This may have to do with how that example has setup the peripheral, how the code calculates the result or possibly the ADC of the CC3200 doesn't measure DC (though I cannot see why not). Possibly someone with more experience with the ADC can step in.

    Glenn.

  • it measures DC and very precise, but a as i meantioned before stores only first cycle of measurement

  • Ok, I've just looked at the example....let's try and clarify some things.

    A sample is a single measurement of the ADC. Are you saying you always get the exact same result for every sample?

    Or are you saying that when you run another "adcdemo 58" for example, the 4096 samples are identical as the 4096 samples taken the first time around?

    Glenn.

  • exactly, but it doesnt matter if i take 4096 samples or just 1. 

    If, lets say, i write "adcdemo 58" with an applied input 1V, it will give me correct reading, but if i write "adcdemo 58" again with an applied different input(for example 0.5V), it will still return me readings from previous input(1V).

  • I'm still not clear. There are 4096 samples being taken. How do you know each of these is identical to the previous (i.e first lot of) 4096 samples?

    Even the most accurate power supply will not be giving the same result for each of the 4096 samples. 

    Are you saying the **scale**  of the sample values has not change?

    Perhaps provide an example that shows 2 different runs of  "adcdemo 58" and show us the last 10 samples in each of these runs, and then explain how you have determined they are the **same**

    Glenn.

  • How do i know? Because i wrote a function that pull from each read 2-13 bits and transform it to actual input value read (in Volts).

    ill provide an example in coming days, i don't have regulated power supply at home.

  • i tried just now with no input applied, and as i explained the result is the same

    measurements on all ADC pins are exactly the same, its not possible

    http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/968/8272.ADC.rtf

  • The output looks different to the output I am getting, I am assuming this is due to the code you have added? Do you get the same result without your added code?....i.e the pure example code without any changes.

    Glenn.

  • My code doesn't change anything, it looks same with it. Without it output would be in hex and contain time stamp+read value, my code is only pulling read value out of it. Thats all.

  • Hi Sergii,

    The observation you have mentioned is result of a known issue in the example code that has been described in the below thread.

    http://e2e.ti.com/support/wireless_connectivity/f/968/p/354092/1243186.aspx#1243186

    Below you can see the relevant portion from the thread referred above.

    #3) Known issue in the demo for multiple execution:

    After printing 4096 ADC samples demo again provides a prompt for further requests. If we provide a request again then the data printed is stale. In order to work around this issue one option is to do a reset. To fix this issue please make the following change in the main() routine which is in main.c file. Inside "while(FOREVER)" loop add "uiIndex=0;" as the first statement. We will fix this in the new release.
    while(FOREVER)
    {
    uiIndex=0;

    ................................................................

    }

    Thanks and Regards,

    Siddaram

  • Hi Siddaram,

    How soon we can expect new release?

    Thank You

  • Hi Sergii,

    This fix is part of the next SDK release but i can't commit on the date of the SDK release, For now you can add the mentioned one line change in your existing SDK example itself and that should work fine. Let us know if you face any issues with that.

    Thanks and Regards,

    Siddaram

  • Hi,

    @Siddaram,

    I think there is another potential bug:

    swru367.pdf, page 365: FIFO level is four words wide; posssible levels: 0x0…0x03. (Table 13-2 name ADC_CH0_FIFO_LVL as “Channel 0 interrupt status register”, section 13.4.1.17 where we find out “ADC_CH0_FIFO_LVL”).

    and on page 369, we can read this:

    5. Read out the ADC samples using following code
    if( ADCFIFOLvlGet(ADC_BASE, ADC_CH_1) )
    {
    ulSample = ADCFIFORead(ADC_BASE, ADC_CH_1) }

    so if the FIFO level is started with 0, the first sample is omitted, due to if construct, since ADCFIFOLvlGet() will return 0! 

    (same test is performed in examples/adc/main.c line 238).

    Petrei

  • Hi Petrei,

    Thanks a lot for your inputs.

    The code is correct but the TRM document mentioning ADC_CHX_FIFO_LVL register is wrong. The document will be changed as below

    Existing : Possible supported levels are : 0x0 to 0x3

    Changed to : Possible supported levels are : 0x0 to 0x4

    Level of 0 indicates that there are no samples in the FIFIO and Level of 1,2,3 and 4 indicates that so many samples are present in the FIFO.

    Thanks and Regards,

    Siddaram

  • Hi,

    I am closing the thread, if issue still exist please open a new thread and add a link to this one for reference