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.

INT- ADC problem in keil

Other Parts Discussed in Thread: TM4C123GH6PM, TM4C123BE6PZ

Customer find ADC module can't work normal, will jump to faultisr when debug. 

I am using our Tiva launchpad to do the same test, find the same problem in KEIL (the version V4.72). but it can run normal in CCS. 

If delete SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS), it can run normal and can get the ADC value. 

if call SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS), will jump to faultisr. 

the source code is as below.

int
main(void)
{
uint32_t ulADC0Value[4];
volatile uint32_t ulTempAvg;
volatile uint32_t ulTempValueC;
volatile uint32_t ulTempValueF;
//
// Enable lazy stacking for interrupt handlers. This allows floating-point
// instructions to be used within interrupt handlers, but at the expense of
// extra stack usage.
//
ROM_FPULazyStackingEnable();

//
// Set the clocking to run directly from the crystal.
//
ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
SYSCTL_XTAL_16MHZ);

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
GPIOPinTypeADC(GPIO_PORTE_BASE,GPIO_PIN_3);

SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS);
ADCSequenceDisable(ADC0_BASE, 1);
ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_PROCESSOR, 0);
ADCSequenceStepConfigure(ADC0_BASE, 1, 0, ADC_CTL_CH0 | ADC_CTL_IE | ADC_CTL_END);
ADCSequenceEnable(ADC0_BASE, 1);

while(1)
{
ADCIntClear(ADC0_BASE, 1);
ADCProcessorTrigger(ADC0_BASE, 1);

while(!ADCIntStatus(ADC0_BASE, 1, false))
{
}

ADCSequenceDataGet(ADC0_BASE, 1, ulADC0Value);
// ulTempAvg = (ulADC0Value[0] + ulADC0Value[1] + ulADC0Value[2] + ulADC0Value[3] + 2)/4;
// ulTempValueC = (1475 - ((2475 * ulTempAvg)) / 4096)/10;
// ulTempValueF = ((ulTempValueC * 9) + 160) / 5;
}

}

  • Do check for the presence of: #include "driverlib/sysctl.h"  (although - presence of, "SysCtlPeripheralEnable()" and its apparent functioning argues against sysctl.h's absence)

    While counter intuitive - you may try this:  Note - I've reversed your listed order of these 2 function calls!  (you must call "SpeedSet" prior to Enabling the ADC!)

    SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

    Note: This ordering "sensitivity" is not required under our IAR 6.60.0 using StellarisWare 9453 and several different LX4F MCUs.  (Your listed way works fine - our system)  This "fix" has past been reported - and confirmed - to work - newer MCUs under some IDEs.  You do not identify your target MCU.  Seems worth the effort - your case... 

    Leave for the reader (or officals) the explanation of such behavior. 

  • thank you for suggestion.

    I have changed my source code follow your suggestion, it can work normal when debug mode is step,bu it can't work  normal when the debug mode is run.  

    my targe IC is TM4C123GH6PM Tiva lunchpad. customer use TM4C123BE6PZ.

     

  • Well - we've tried - "fix" I described was reported here using (95% certain) one of the rebrand MCUs and either Keil or CCS. 

    After producing that write-up for you - ran similar code on our board w/IAR - and could not cause any ADC "breakage."  However our MCUs are pre-rebrand LX4Fs and we operate under StellarisWare - so "apples to apples" may not entirely be in play.

    System Control chapter - your MCU manual - should reveal key System Control Registers ending in ADC.  Again - no matter the order in which I called ADC or SysCtl functions - could not "spoil" any!   You may wish to repeat that analysis using Keil - and see if you can discover the "upset mechanism." 

    The Sys Ctl Registers I monitored earlier today all revealed their ADC bits set = 1 when "tickled" by either Sys Ctl or ADC functions.  Suspect that the offending function will clear an ADC bit - and that yields your fault...