Problem while running the ADC code

Thanks Amit for looking into the matter. But that replacement is not solving the problem. I had tried this replacement from the ROM file but still it is calling the exit() routine before staring the A/D conversion. 

Hi,

Keep a breakpoint to second line in while(1) loop and Run the program.

If its comfortable for you means please post ur code here

Hello Snigdha,

Haresh's point will stop the function from reaching the exit condition, However did you try replacing the external clock with an internal clock or did you try replacing the existing function with the ROM version of it. Please do clarify?

Regards

Amit

I am pasting the code here. I have clarified with comments wherever necessary.

#include <stdint.h>

#include "tm4c1294ncpdt.h"

#include <stdbool.h>

#include "hw_memmap.h"

#include "adc.h"

#include "gpio.h"

#include "pin_map.h"

#include "sysctl.h"

#include "uart.h"

#include "uartstdio.h"

#include "driverlib/rom.h"

unsigned char ip, cmd[5]= {0x38,0x0E,0x01,0x06,0x80}; //LCD Initialization commands

void blink(void) //Func for simple LED blinking

{

volatile uint32_t ui32Loop;

GPIO_PORTN_DATA_R |= 0xff;

for(ui32Loop = 0; ui32Loop < 200000; ui32Loop++)

{

}

GPIO_PORTN_DATA_R &= ~(0xff);

for(ui32Loop = 0; ui32Loop < 200000; ui32Loop++)

{

}

}

void smalldelay(void) //High to Low Pulse Delay

{

volatile uint32_t x=0;

for(;x<20000;x++){}

}

void delay(void) //Busy Delay

{

volatile uint32_t x=0;

for(;x<800000;x++){}

}

void wrtcmd(void)

{

GPIO_PORTM_DATA_R &= ~0x40;

GPIO_PORTK_DATA_R &= ~0xFF;

GPIO_PORTK_DATA_R |= ip;

GPIO_PORTM_DATA_R |= 0x80;

smalldelay();

GPIO_PORTM_DATA_R &= ~0x80;

}

void lcdinit(void)

{

int i;

for (i=0;i<5;i++)

{

ip=cmd[i];

wrtcmd();

delay();

//blink();

}

}

void wrtdata(void)

{

GPIO_PORTM_DATA_R |= 0x40;

GPIO_PORTK_DATA_R &= ~0xFF;

GPIO_PORTK_DATA_R |= ip;

GPIO_PORTM_DATA_R |= 0x80;

smalldelay();

GPIO_PORTM_DATA_R &= ~0x80;

}

void disp(unsigned char x)

{

ip=x+0x30;

wrtdata();

delay();

}

void main(void)

{

unsigned char x=0;

SYSCTL_RCGCGPIO_R = 0x00001A00;

GPIO_PORTN_DIR_R = 0xff; //Ports used for LCD and LED blink

GPIO_PORTN_DEN_R = 0xff;

GPIO_PORTK_DIR_R = 0xff;

GPIO_PORTK_DEN_R = 0xff;

GPIO_PORTM_DIR_R = 0xff;

GPIO_PORTM_DEN_R = 0xff;

lcdinit(); //Initialize LCD

disp(x); //Checking Display

//ADC Part

uint32_t value[1],temp;

blink(); //Blinking before setting clk freq

SysCtlClockFreqSet((SYSCTL_XTAL_16MHZ | SYSCTL_OSC_INT | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);

blink(); //Code never reaches at this point

SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);

GPIOPinTypeADC(GPIO_PORTE_BASE, GPIO_PIN_0); // Hanging here when SysCtlClockFreqSet() is commented

//using portE-pin0 i.e. Analog Input 3

blink();

ADCSequenceConfigure(ADC0_BASE, 3, ADC_TRIGGER_ALWAYS, 0);

//using sequencer 3 coz of only 1 i/p presently

blink();

ADCSequenceStepConfigure(ADC0_BASE, 3, 0, ADC_CTL_CH3|ADC_CTL_IE|ADC_CTL_END);

//Instruct ADC to sample o/p, generate interrupt and indicate this is the final sample in the sequence

blink();

ADCSequenceEnable(ADC0_BASE, 3);

while(1)

{

ADCIntClear(ADC0_BASE, 3);

ADCProcessorTrigger(ADC0_BASE, 3);

while(!ADCIntStatus(ADC0_BASE, 3, false))

{

}

ADCSequenceDataGet(ADC0_BASE, 3, value);

temp=value[0]%1000;

x=temp/100;

if(x) disp(x);

temp=value[0]%100;

x=temp/10;

disp(x);

x=value[0]%10;

disp(x);

}

//End of ADC Part

}

And I tried out the ROM version just to give it a try. But even that didn't work.

Hello Snigdha,

Please zip the CCS project and send it over so that we can see on the EK-TM4C129 as to why you are having such an issue

Regards

Amit

Yes sure. May I please know the email id on which I am supposed to send it?

Hello Snigdha,

You can attach it to the E2E Post.

Regards

Amit

1526.adc_with_lcd.zip

Ya I copied the line as it was from the tutorial. The only things which are done before that are initializations for o/p ports and the LCD. 

Ok. So what should be a solution to this? Because just stepping over the function makes the code hang at the declaration for the Analog pin.

snigdha narra said:

implementing an ADC code on TM4C1294NCPDT

I'm not smart or (psychic) enough to tell - from the above - if yours is "official" or custom board.  (custom subject to any/everything which may be, "out of spec.")  Such is the "rule" for any new, custom board - not a personal criticism.

Are a proper - 25MHz xtal - and its specified bypass caps - implemented in close proximity to the MCU's xtal pins?

Blinking an Led is far preferable to confirm (some) operation - the "hoped for" (write then clear) of the Lcd is far more complex & demanding - thus imho should be a (far later) not early test.  (and I don't like that Lcd code - but such is not for here/now...)

As others have commented - its "normal" to set the system clock very early w/in main - and only then initialize peripherals - and the critical "start-up" file must be present.

Lost here is the (most always) "sound advice" to NOT create your own project - instead "piggy-back" upon a known good, vendor supplied project!  "Creating your own" escapes many/most/all of the special IDE "hooks/treatments" - automatically provided by vendor projects!  Is that wise?  ("Pride of authorship" lands many sailors - and those here - on the rocks!  (i.e. I simply "sail" my boat - I don't reinvent nor attempt to design it))

Lastly - much use of direct register reveals - often for "one-time" set-ups/configs - where any benefits are minimized - and a mistake likely will be critical.  Is that wise?  Driver Lib far easier - and effective - and easier for those here to test/troubleshoot. 

@petrei, @marc_rir, @amit  Sir,

Setting the frequency in the very first line solved the major part of the problem. And the startup file was somehow not getting added earlier. It got added after creating a new project altogether. And the #include statements were modified as tivaware was not linking directly.

But the A/D conversion is successful now finally on the hardware.

Thank you all very much for looking into it.

While unmentioned/unawarded - today's 05:38 post neatly encapsulates all of these key points - while (gently) guiding users AWAY from the guaranteed disaster which results when, "Creating OWN Project!"

Might, "Creating OWN Disaster/Time-Waster/Morale Sapper" be valid replacement for the 99% who attempt to, "Create OWN Project?  False pride damages more often than we like to admit.

Hello cb1

Do you think we should add the same to "Torubleshooting Tips and Trick" post

Regards

Amit

@ Amit,

It's never explained "why" users so desire to, "create their own."  As a reasonably successful small, tech business - employed by multiple, far larger firms - I can report that neither those "giants" nor our size firm - strive to, "Create our own!" 

Instead - both giants & we - most always search for & acquire, "closest matching product or software package."  Neither giants nor we seek to, "Reinvent the tech wheel!"  Instead - by studying the efforts of (skilled) others - we often glean vital data and learn from their approach.  To start from scratch - to "create your own" most always causes prolonged development time - and less than, "best/brightest" design result.

And - while we use multi-seat, paid IAR & most here use (free) CCS - the mastery of IDEs over-challenges all IDE users.  IDE's prove an, "equal opportunity frustrator/deadline-killer/morale sapper!" 

Is not the (major) goal the increased understanding of the MCU & it's programming?  The IDE as a "roadblock" to such makes NO sense!   Your firm has invested great time/energy in creating fully debugged, known good projects, covering a variety of typical applications.  Jumping from the safety of this lifeboat - unexplained - when hungry sharks abound -  does not seem especially well thought nor considered...

I'd place, "Use one of the provided projects - do NOT attempt to, "Create your own!" prominently w/in your sticky post.

So much time/effort/productivity has been lost by "my own" posters. (including our group)  Of note - the justification for, "creating one's own" never appears!  To best discourage such "invention" you may state that forum support will not be supplied to those who, "create their own" - it clearly dilutes a rare & precious resource (your time/efforts) - and for what?