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 count freezes at (2^n)-1 value on TM4C1290NCPDT

Dear Sir

Iam facing some issue  related with ADC.Please go through the test setup and problem statement given below 

Details of the Setup

Microcontroller :-TM4C1290NCPDT

IDE:-CCS 6.0.1.00040 

Compiler:-TI V 5.1.11

Emulator:-XDS100V2

Target board:-customized target board

Crystal Frequency:-8Mhz

System Frequency:-120Mhz

ADC sampling frequency :-8Hz (This frequency is achieved by using Timer Trigger mode)

ADC Ref:-3V

ADC input :-0 to 3V DC

ADC configuration :-Single ended

ADC 0 sampling logic:-

ADC is triggered using Timer trigger(Timer 7 is used).It will trigger the ADC every 125mS and data is collected using ADC ISR. Sequence 2 is used.4 channels are configured in sequence 2 and interrupt is enabled at the step4 of sequencer.In that 4 channels two channels are used for measurement and the remaining two used as a Dummy channel to avoid cross talk between measurement channels.Input to the Dummy channel is connected to ground to ensure 0 input

Problem statement

Whenever the input to ADC is given corresponding to 2^n-1 (ie 2047,1023, 511, 255,127,63 etc) value then ADC count is freezing to the corresponding 2^n-1 value. We collected these data in a array of 100 values at every 125mS. All values are getting rock steady to these magical values(2^n-1). Input to ADC is DC with some unwanted noise,so as per the input, the ADC count should vary  in between 5-15 counts but as soon the ADC count reaches to these magical value there is no single count variation.For other count values it is working as expected.

To come out of these magical values the input need to change substantially in value corresponding to  20 - 30 counts.It will work fine as soon as it come out of the magical value.These problem is happening in measurement ch1 as well as measurement ch2. One more finding is, problem in one channel is not affecting other

Test case:

742mVDC is corresponds to 1023counts and these counts remain constant for a input variation from 735mVDC to 780mVDC .But actually it should vary from 1013 to 1076counts.For other than magical values ADC counts varing corresponds to the input variation even for 2mVDC

 Please find the attached for code snippet,results and block diagram.

Thanks in advance for any suggestions.

//ADC
#define DEF_CH1ADC_CAL1 GPIO_PIN_7  //PD7
#define DEF_ADC_DUMMY GPIO_PIN_6  //PD6.....This Pin is used for Dummy ADC //read to avoid cross talk
#define DEF_CH2ADC_CAL1 GPIO_PIN_5  //PD5
uint32_t g_ui32ADC0Value[8];
uint32_t g_ui32ADC0TempValue[100];
uint8_t g_ui8ADCTestcnt=0;
uint32_t g_ui32SysClock;

Void main(void)
{

	SysCtlPeripheralReset(SYSCTL_PERIPH_ADC0);
	g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_8MHZ |SYSCTL_OSC_MAIN |SYSCTL_USE_PLL |SYSCTL_CFG_VCO_480), 120000000);

	IntMasterEnable();

	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);//for ADC

	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
	
	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER7);

	MAP_SysCtlDelay(51);    //51*3 clk cycles=1.275uS


	MAP_TimerDisable(TIMER7_BASE,TIMER_BOTH);
	MAP_TimerConfigure(TIMER7_BASE,TIMER_CFG_PERIODIC);
	MAP_TimerControlTrigger(TIMER7_BASE,TIMER_BOTH,true);
	MAP_TimerADCEventSet(TIMER7_BASE,TIMER_ADC_TIMEOUT_A);
	MAP_TimerLoadSet(TIMER7_BASE, TIMER_BOTH, 15006002);//for 125ms=8.33nS*counts.........1/120Mhz=8.33nS
	MAP_TimerEnable(TIMER7_BASE,TIMER_BOTH);
	

	MAP_GPIOPinTypeADC(GPIO_PORTD_BASE,DEF_CH1ADC_CAL1);//single ended
	MAP_GPIOPinTypeADC(GPIO_PORTD_BASE,DEF_CH2ADC_CAL1);//single ended
	MAP_GPIOPinTypeADC(GPIO_PORTD_BASE,DEF_ADC_DUMMY);//This Pin is used //for Dummy ADC read to avoid cross talk
	MAP_ADCSequenceDisable(ADC0_BASE, 2);
	MAP_ADCReferenceSet(ADC0_BASE,ADC_REF_EXT_3V);
	ADCSequenceConfigure(ADC0_BASE, 2, ADC_TRIGGER_TIMER, 0);
	


	ADCSequenceStepConfigure(ADC0_BASE, 2, 0,ADC_CTL_CH5);//Dummy read	ADCSequenceStepConfigure(ADC0_BASE, 2, 1,ADC_CTL_CH4|ADC_CTL_SHOLD_8);//single ended..for CH1	ADCSequenceStepConfigure(ADC0_BASE, 2, 2,ADC_CTL_CH5);//Dummy read
	ADCSequenceStepConfigure(ADC0_BASE, 2, 3,ADC_CTL_CH6 |ADC_CTL_IE |ADC_CTL_SHOLD_8| ADC_CTL_END);//single ended..for CH2


    MAP_ADCSequenceEnable(ADC0_BASE, 2);
    MAP_ADCIntClear(ADC0_BASE, 2);
	
	IntEnable(INT_ADC0SS2); // Enable interrupt for adc 0 ss 2
	ADCIntEnable(ADC0_BASE, 2);
While(1)
{
//calculations
}
}

void ADC0Seq2IntHandler(void)
{
	  ADCIntClear(ADC0_BASE, 2);
	  ADCSequenceDataGet (ADC0_BASE, 2, g_ui32ADC0Value);

       //Ch1 measurement data                                                  
	  g_ui32ADC0TempValue[g_ui8ADCTestcnt++]=g_ui32ADC0Value[1];                                                                     
	  if(g_ui8ADCTestcnt>=100)
	  {
		  g_ui8ADCTestcnt=0;
	  }
 

}

  • satheesh kumar said:
    ...the remaining two used as a Dummy channel to avoid cross talk between measurement channels.Input to the Dummy channel is connected to ground to ensure 0 input

    Excellently composed & detail-rich post - Bravo!

    Firm/I have used these & predecessor parts coming upon ten years - never/ever have we noted such an issue!   (and we have "swept" the ADC inputs - so surely we've introduced your, "magic ADC values.")

    Now your attempt to "avoid" cross talk - as described w/in the quote - I believe "fails" as the 0V introduction will tend to "weaken" the following reading.   Might the "back to back" presentation of the SAME Channel data - instead - prove the best means to "avoid or reduce" such cross-talk?   I'd discount the first reading - accept & process (only) the 2nd reading - thus the first reading serves as a "cross-talk reducing" dummy reading.  (this is so as the "difference between signal levels - upon consecutive ADC steps - reveals the greatest "cross-talk" levels."   Thus - should your desired signal swing far from ground - you've "encouraged" (not avoided) such cross-talk by the introduction of 0V!)

    Absent in your (otherwise) excellent report is the "population of boards" which reveal this issue.   The diagnosis may vary greatly based upon the number of boards impacted.

    As a swag - I'd suspect your unpacking & read of the FIFO - rather than an MCU "sensitivity" - to such "magic" voltage levels...

  • Hello Satheesh,

    Is it possible for you to post a simplified project that reproduces the symptom so I can debug on my bench? I too would suspect something going on with reading of the FIFO like a pointer not getting incremented or something.
  • cb1 makes excellent points, I've a few questions and suggestions in addition.

    You don't mention what kind, how large or even if you have a capacitor on the A/D inputs or what the source impedance is. Also whether you have a resistor in series with the charge storage capacitor to eliminate high frequencies.

    From the description with a ramp test as cb1 describes you should see missing codes. I'd want to perform a simple test with a ramp if at all possible and make a histogram showing the occurrence of each value during that test. I'd want to compare that to a known good measurement of the ramp taken at the same time.

    I'd also want to verify that the known good measurement of the ramp alone showed no evidence of the such stepping.
    Measure both the input to the signal conditioning and the input to the A/D

    If the problem does show up I'd repeat at several ramp rates, all slow enough to have multiple samples at each code

    Basically I'd want to verify that the problem occurred and that an independent measurement shows no such problem with the actual signal. Suspect everything - the signal generator, the reference reading and the signal conditioning as well as your A/D.

    Robert
  • Robert Adsett said:
    Suspect everything!...

    Classic - and friend Robert nails it - once again...   We really need to know the percentage of your boards exhibiting this condition.

    Even though "much data" has been presented - it is rare that "sufficient" data arrives...

  • Yes, multiple boards and it just occurs to me, you should check the reference as well. If both the reference and the input change at the same time you will see non-linearitys.

    Robert
  • And (clearly I've too much "free time" today) might this "magic/stuck" reading suggest an unwanted switch from, Single-Ended to Differential ADC configuration?   And/or a, "tracking" between these 2 subject ADC Channels?

    Robert's suggested "measure everything" should include (simultaneous) measure/monitor of BOTH suspect channels.   And poster should fully describe "how each errant ADC channel is being driven" and how the changed voltage level at one channel effects (if at all) the voltage level at the 2nd channel.  (such was "touched on" by poster - yet not fully detailed)

  • Just noted that the (always) delightful "NMI" afflicts your PD7 - and you've "failed" to free that pin from its NMI BURDEN!  

    *** this PD7 as NMI inflicts 4C123 - I don't know if this extends to your 4C1290!   Surely worth the mention...

    Per usual - vendor minimizes their "deviations" and PF0 & PD7 (partners in NMI crime) appear briefly (in mice type) w/warning of this insidious (and always unwanted) default behavior.

    Clearly you need to exit from PD7 (too risky IMO) and employ another ADC pin - & repeat your testing.

    I've no explanation for the effect you've presented - yet using any "locked pin" w/out unlocking - clearly proves NOT "best/brightest."   Suggest that you flee - quickly & far from PD7 - and employ a "normal" (mice-type free) ADC pin.

  • Dear Robert,
    Thanks for the prompt reply.
    Yes what you said is correct.The culprit is Vref to the ADC.We did not used 1uF and 0.01uF capacitor to the output Vref circuit because of the oscillation issue since we are generating a 3V ref from a 2.5V voltage regulator using Op-Amp. this Op-Amp tend to give oscillations when capacitor is connected at its output.
    Finally now we again used those capacitors with some additional circuit to eliminate osculations

    Now ADC is not freezing at those magical values.Only question remaining is why ADC is freezing at only those magical values when it is working with all other values perfectly

    Thanks once again robert .your valuable suggestions helped us to arrive the solution
  • Dear cb1,
    Thanks for the prompt reply.
  • Dear Robert,
    Thanks for the prompt reply.
  • Satheesh - Really, who cares? You must comply w/(any) MCU maker's directives.

    Failure to comply exposes you to multiple, unspecified behaviors - never/ever a good idea! Issue you note IS a curiosity - but is unlikely to boost your (school) class-standing or bottom-line... Allez!

  • I agree with cb1 that ultimately the reason doesn't matter in the sense you must comply with the manufacturer's restrictions. And the reasons for those restrictions may be a result of implementation details that the vendor may not reveal.

    I am less cavalier in suggesting there is no benefit. Having some idea of why those restrictions are present can be of use.

    In this particular case consider that the converter is AFAIK a Successive Approximation converter and probably capacitor based. As a result there will be short spikes of current drawn from the reference as the A/D converges on the result. If the reference cannot react fast enough it will drop as the current demands spike and rise when they are withdrawn. Fast enough is orders of magnitude faster than the conversion rate which is already faster than the sampling rate.

    That forces a very fast supply or a capacitor with sufficient capacitance that the charge withdrawn makes little difference to the reference voltage.

    There may be additional restrictions as a result of the manufacturer's specific implementation but that basic outline already should give you ideas on what else could go wrong.

    Robert
  • That's probably correct.

    The "usual" SAR-ADC implementation contains a DAC to convert the step-by-step intermediate conversion result back to an analog value, and a comparator to provide the next result bit. Both load the reference source, especially during value transitions (which happen <n> times for a <n>-bit ADC).

  • Mes deux amis,   (R.A. & f.m.)

    When you two agree - mere mortals must, "fall in line."  (I was not smart/aware enough to analyze as well)

    However - there is a "mission" and there are "incidentals."   Many such "incidentals" will be encountered during design/development - some may prove of value - but my findings reveal that "best practice" is to (note) these - and return to one's central task/mission.

    Once a week my small group meets - scan the incidentals - and weigh each for possible benefit/cash-generation.   When the incidentals are (often unwisely) promoted - the main job will suffer - and usually the incidental remains unresolved.

    Focus, discipline, sweating the (proper) project details aids greatly in keeping the firm's door "open."   Studies reveal (some) correlation between "attention deficit" and high IQ.   I submit that there's a "time & place" for incidental investigation/resolution - and that over-promotion too often proves mission defeating...

  • My concern in this case would be less the opportunity than the additional insight the understanding gives to other issues and secondarily the risks highlighted by that knowledge that are not readily apparent from the vendor's cookbook.

    It is this reason that items that are done "because they work" give me sleepless nights. And vendors who only supply cookbook solutions are a special headache.

    Exploitable opportunities are tertiary concerns.

    And yes, not too much time should be devoted to it but it is a valid question with real risks. As far as how much time, that may depend on who's asking the question, surely worth more time for a student to explore since the possible payback accumulates over a longer time and indeed may multiply by the insight it gives in areas that are not obviously connected.

    Robert
  • While many of your points are valid - you shrink from the (likely) abandonment of the "central mission" - due to seduction via the incidental.  

    Is it not rare for only "one" incidental to bubble up?   (especially when - like poster - active/probing minds are "in play.")

    Method outlined (noting/logging the incidentals - but not promoting) has proved effective in keeping us "on track."   I believe our "group think" better judges the, "Valid question & risk assessment" than would be possible by (single) observer, alone...