Problem in GPIO configuration

Hello Forum User

What is the intent of the following function call? Divide by 1 or Divide by 2.5! Use Internal oscillator or use external oscillator

ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |SYSCTL_XTAL_16MHZ|SYSCTL_SYSDIV_2_5);

Also it is not clear what the issue is. Is there a bus fault?

Hello Forum User

My first few questions still remain unanswered. Might information be provided for the same?

Hello Forum User,

If you intent to use 80MHz then the correct configuration should be

ROM_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |SYSCTL_XTAL_16MHZ);

Also after enabling the clocks to the Peripheral check the peripheral ready for access using the following statement after enabling it

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
while(!(ROM_SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOA)));

Thanks for ur reply...but still the same issue..Pins are giving low logic

I have done what u said..

Hello Forum User,

Is there still a Bus Fault?

Hello Forum User,

Can you please check the Fault Status register and Fault Address register as provided in the following post.

e2e.ti.com/.../374640

Thanks for ur reply Amit Sir!! Well what I have configured when I load the code,the controller dosent respond until and unless I have pressed the reset button...And when I pressed reset button the code runs fine..Means the pins are giving me high logic

My question is why there is a need to press reset button??

Hello Forum User

You have yet not provided the details on what the Fault registers show the issue as.

Hello Amit,

If I may - as poster did not fully grasp, "scope capture" - is it not likely that, "Fault registers" will also confound?

Suspect that neither you nor I could find fault w/in his few lines of code (other than the SysClock foul up - which you id'ed & corrected).

In such (typical) "Runs only upon Reset" scenario - does not the presence and/or correctness of the, "Start-Up file" blip the radar?    God help us if that too has been relegated to the (always) delightful DRM code style...

You are just executing past the end of main and performing an implicit return. Returning from main in an embedded system is not a good idea.

Relying on the runtime to do what you want on a return from main is asking for trouble, there is not 'right' action for the run-time to take.

This might not be an issue but you probably want an infinite loop there.

Robert

Hello cb1

The reset provided in CCS has the default set to CPU reset and not affecting the peripheral (a mistake made by quite some users). Prefer to use the System Reset. I agree the only suspect looks to be the Start Up file, but I can get my head around it as to if there may be anything else that is being overlooked.