Using switches in Tiva Launchpad

Hello Shyam,

This is one of the most long and outstanding threads on the forum. PF0 is a locked pin. You need to unlock the pin, by using GPIO_LOCK register write, followed by the GPIO_CR bit fr PF0 being set to 1 and then call the GPIOPinTypeGPIOInput API call to get PF0 as a GPIO.

HWREG(GPIO_PORTF_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

HWREG(GPIO_PORTF_BASE+GPIO_O_CR) |= 0x01;

GPIOPinTypeGPIOInput(GPIO_PORTF_BASE,GPIO_PIN_0);

Regards

Amit

Perhaps even longer - and more outstanding - is the document author's outright refusal to admit defeat - and provide far more notable NMI cautions & safeguards!  (What iceberg - full speed ahead!)

Perhaps some care/consideration for the plight of hapless users - who regularly fall victim to the "proven ineffective," existing NMI warnings - could ping the doc staff's radar...

Long urged (far beyond suggested) was the attachment of "***NMI pin (read caution note)"  to each/every reference to pesky NMI pins (usually PF0 & PD7).  Even further - NRND proclamation - splashed across top of page 1  (each/every forsaken M3 MCU) employed use of color - to better impact the reader.

While the able (and likely exhausted) vendor staffer (surely not doc author) posts (again) NMI post mortem here -such necessary NMI detail (unfortunately) is very predictably missed by the clear majority of new users.   

Is not the "NIH" suggestion (repeated above) superior to, "piecemeal bandaids" (i.e.  those placed here) - after yet another (valued?) user/client has succumbed?      Ans: Yes - "prevention" most always trumps any "cure!" 

Hi Amit,

Thanks for clearing my doubt. I have one more problem with my launchpad. This is the COMPLETE program which I burned in the controller.

#include <stdbool.h>
#include <stdint.h>
#include "driverlib/adc.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"
#include "driverlib/rom_map.h"
#include "driverlib/sysctl.h"
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "inc/hw_gpio.h"

int main(void)
{
    SysCtlClockSet(SYSCTL_SYSDIV_10|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);
    uint8_t i=0;
    HWREG(GPIO_PORTF_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTF_BASE+GPIO_O_CR) |= 0x01;
    GPIOPinTypeGPIOInput(GPIO_PORTF_BASE,GPIO_PIN_0);

    while(1)
    {
        if( (GPIOPinRead(GPIO_PORTF_BASE, GPIO_PIN_0) != GPIO_PIN_0))
        {
        	SysCtlDelay(SysCtlClockGet()/10);
        	i++;
        	if(i%3 == 0x00)
                GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,0x02);
        	if(i%3 == 0x01)
                GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,0x08);
        	if(i%3 == 0x02)
                GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,0x04);
        	SysCtlDelay(SysCtlClockGet()/30);
        	while((GPIOPinRead(GPIO_PORTF_BASE, GPIO_PIN_0) != GPIO_PIN_0)){}
        }
    }
}

The problem I am facing is after burning the code I am able to change colors by pressing the button. But when I plug out the USB from the PC and plug it again, the code does not run. I had to burn it again for using it. Is there a way to make the code run even after removing and plugging it again ?

Appears to this (unaddressed) reporter that dreaded, "start-up file" is rising in the ranks - starting to approach famed NMI - in, "lack of clear, emphatic presentation..."

Pity that poster shows little concern for his fellows (i.e. help me - only!) after falling victim to doc "inadequacy."

Hello Shyam,

After the SysCtlPeripheralEnable add a delay loop uisng

SysCtlDelay(10)

After enabling a peripheral there are a few clocks required for the clock to start.

Regards

Amit