Struggling to make GPIO work on DK-TM4C123G

Besides the data sheet read, quick code is here

http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/313777/1092602.aspx#1092602

Amit

Should the existing MCU data manual too "bury" this critical data - this reporter's long suggested "improvement" can be found here: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/178203.aspx

Post is time-stamped:  15:19, 22 Jan 2014...

Thanks for the quick response guys.  I fixed it with your help.  For others treading in my footsteps, here's the code that worked...

#include "inc/hw_types.h"
#include "inc/hw_gpio.h"

void ConfigPBBpins (void){

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0x80; 				//
    HWREG(GPIO_PORTD_BASE + GPIO_O_AFSEL) &= ~0x80;
    HWREG(GPIO_PORTD_BASE + GPIO_O_DEN) |= 0x80;
    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;

	ROM_SysCtlPeripheralEnable (SYSCTL_PERIPH_GPIOD);
	ROM_GPIOPinTypeGPIOOutput (GPIO_PORTD_BASE, 0xC0); // outputs for 2-color LED
	ROM_GPIOPadConfigSet(GPIO_PORTD_BASE, 0xC0, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);

}

Thank you, Sir - appreciated.

Issue arises so often - likelihood of new user landing here - finding this insight - highly doubtful.

Long suggested improvement (i.e. bloody properly/repeatedly highlight this "unexpected" behavior) long sits/languishes due to (one assumes) NIH! 

And the trade press now reports significant misfortune - this embedded division - perhaps there is some connection...

Hmmm,

Now I have an issue where this has stopped working - it sometimes gets into a FaultISR in startup_css.c and single stepping seems to show that it's getting an NMI when I get to the AFSEL line in the snippet below...

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0x80; 				// GPIO Ctrl Reg
    HWREG(GPIO_PORTD_BASE + GPIO_O_AFSEL) &= ~0x80;			// Alt Funct Select
    HWREG(GPIO_PORTD_BASE + GPIO_O_DEN) |= 0x80;			// Digital Enable
    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;				// Lock back on

Any suggestions for what I can test to see what's the cause iof this?

Hello Ted,

Can you change the GPIOPCTL to 0x0 before clearing AFSEL?

Regards

Amit

Amit,

Are you suggesting that I add a line or do you want me to edit the existing line as follows...

HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0x0;

Hi Ted,

Added the line before unlock sequence.

Regards

Amit

Hi Ted,

Added the line before unlock sequence.

Regards

Amit

Your past code (which you reported as, "worked"):

void ConfigPBBpins (void)
{

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0x80;     //
    HWREG(GPIO_PORTD_BASE + GPIO_O_AFSEL) &= ~0x80;
    HWREG(GPIO_PORTD_BASE + GPIO_O_DEN) |= 0x80;
    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;

 ROM_SysCtlPeripheralEnable (SYSCTL_PERIPH_GPIOD);
 ROM_GPIOPinTypeGPIOOutput (GPIO_PORTD_BASE, 0xC0); // outputs for 2-color LED
 ROM_GPIOPadConfigSet(GPIO_PORTD_BASE, 0xC0, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);

}

Should not that (red) be placed earlier in the code sequence?  (i.e. prior to "any access" of Port D!)  Failure to properly enable any MCU peripheral prior to its use - "normally/customarily" causes a fault.  Advancing that (red) function atop function sequence - provides quick/easy test...  And - you should then provide a short delay - prior to any futher accesses to Port D - to enable Port D to properly enable.

The use of other's suggested: "HWREG(GPIO_PORTD_BASE + GPIO_O_PCTL) = 0x00;" seems w/out substantial merit for these reasons:

a) GPIO_O_PCTL defaults into 0x00 (per my LX4F manual) - and confirmed via IAR register view upon pwr up.

b) No such early (top) appearance of  "GPIO_O_PCTL" - during the unlock sequence - has been past directed, nor well noted.  That's not especially compelling - but is this "addition" announced as a, "just discovered" Unlock Breakthrough? If that's not the case -has it not been terribly under-promoted?  (i.e. struggling poster here could not find!)

c) The forcing of, "GPIO_O_PCTL" to zero is far too harsh - clears all bits - when really only bit 0 (PD0 config) should be so targeted. (i.e. "All other Port D pins are impacted by this, "too heavy hand!"

Amit,

I added the line of code you suggested and it doesn't seem to make any difference.

cb1_mobile
I commented out Amit's line and tried moving the line you suggested but again no difference. What is weird though is this -

As long as I'm connected via the debug USB cable, things seem to run OK with the HWREG lines in the code but only while I power the board from the USB cable and program + run it via debug build.

When I press the stop button in CCS, disconnect the USB cable, and power up the board from a 5V bench PSU, although the power light comes on, my program doesn't run if the HWREG lines are in the programmed code - I'm assuming that it's getting stuck in the FaultISR as the on-board power LED does come on but nothing else.

Now if I comment out the 6 x HWREG lines and repeat the above 2 steps, it runs no problem from any source although I don't get the LED on PD7 to flash obviously.

Is there something I don't understand about debug mode via the ICSD connector that would interfere with the normal (non-debug) running of my device? Does debug mode add overhead code to the CPU? Should I be programming directly for a non-debug run?

This is frustrating but I do appreciate the help you guys are giving.  Current code listing is as follows:

	ROM_SysCtlPeripheralEnable (SYSCTL_PERIPH_GPIOD);

//	HWREG(GPIO_PORTD_BASE + GPIO_O_PCTL) = 0x00;            // GPIO PCTL
/*	HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0x80; 				// GPIO Ctrl Reg
    HWREG(GPIO_PORTD_BASE + GPIO_O_AFSEL) &= ~0x80;			// Alt Funct Select
    HWREG(GPIO_PORTD_BASE + GPIO_O_DEN) |= 0x80;			// Digital Enable
    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;				// Lock back on
*/
	ROM_GPIOPinTypeGPIOOutput (GPIO_PORTD_BASE, 0xC0); 		// D7..6 are outputs for 2-color LED
	ROM_GPIOPadConfigSet(GPIO_PORTD_BASE, 0xC0, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);

	ROM_SysCtlPeripheralEnable (SYSCTL_PERIPH_GPION);
	ROM_GPIOPinTypeGPIOInput (GPIO_PORTN_BASE, 0x3F); 		// N5..0 are inputs with weak pullup for buttons
	ROM_GPIOPadConfigSet(GPIO_PORTN_BASE, 0x3F, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);

@ Ted,

I'm confounded by the fact that earlier the report was, "Suggested unlock solved."  And now - disaster.

Our group uses MCUs from many - and a "real" IDE (IAR) which has powerful JTAG debugger probe and operates via more modern/improved, SWD as well.  (freeing 2 MCU pins - our use)  So - I cannot assist w/CCS dilemma.

Had you added any code - which may have impacted PD7 - after you unlocked it?  I'd certainly raise that search in your que. 

An unfortunate issue that we see - so often - and so litlle corrected - is the necessity to become IDE-maven to achieve basic MCU functionality.  (thus - our use of IAR)  Might you (temporarily) solve your issue by simply abandoning (problematic) PD7 - and substituting a "less demanding" pin?  Your progress is being derailed by this hiccup - as a business - I can't allow such to persist w/my staff. 

Note that your most recent code (still) calls no "delay" just post the enable of Port D.  I continue in the belief that the "novel" (brand new) employ of GPIO_O_PCTL - clearly too broad in its scope - is off target in your rescue...

And - now dawns - certain of those launchpads made the (many feel) unwise - deliberate pin to pin connection of your MCU.  (we're told this was done to "maintain compatibility w/past board - not an ARM!")  (Suggest that skilled decision maker search for nearest, tall bldg...)  Should PD7 be so victimized - such may contribute to your dilemma.  Review of your board's schematic will reveal...

Hi Ted,

See, post below with code snippet by cb1 to unlock PD7. Take note of the difference, compared to your unlock code.

TM4C123 NMI unlock

Try this below. I based this from the ButtonsInit().

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
HWREG(GPIO_PORTD_BASE + GPIO_O_CR) |= 0x80;
HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;

ROM_GPIOPinTypeGPIOOutput (GPIO_PORTD_BASE, 0xC0);

-kel

@cb1
Sorry you're "confounded", I correctly gave you credit for identifying that PD7 defaults to NMI functionality which was the root cause of my issue and you did solve it. Thank you.

I guess I should have raised a new post to try to dig into why the code works when the board is plugged in to the debug connection but not when powered alone - but I didn't because it only doesn't work when the new code is enabled. More honestly, I was hoping to continue to mine the deep seam of experience that I had already found in this thread :D

You may be right that Code Composer Studio (CCS) is causing the problem, I have had occasions where my dev board stops working but works again after I restart CCS; I have considered moving to IAR or Keil and this may be the reason for doing so.

Meanwhile, I'm still curious to know what, if anything, CCS does to the TM4C123G CPU to run it in debug mode - in the Microchip PIC world, the debug system puts additional code onto the PIC and steals a level of stack from the user. I had been advised by a trusted friend that CCS does not do that and there is no difference in what is programmed on the chip between release and debug mode but is he right?

@Markel
Thanks for your input, I'll revisit and check the differences in detail but I won't get to it until Monday.

Hi Ted,

I tried the same thing with CCS and I see both PD7 and PD6 LED's working with both methods of USB Power and PSU Power.  Following is the code

Please do note that I am not using PLL but instead running it at 16MHz Clock.

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;

    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) |= 0x80;              // GPIO Ctrl Reg

    HWREG(GPIO_PORTD_BASE + GPIO_O_AFSEL) &= ~0x80;         // Alt Funct Select

    HWREG(GPIO_PORTD_BASE + GPIO_O_DEN) |= 0x80;            // Digital Enable

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0;               // Lock back on

    GPIOPinTypeGPIOOutput (GPIO_PORTD_BASE, 0xC0);      // D7..6 are outputs for 2-color LED

    GPIOPadConfigSet(GPIO_PORTD_BASE, 0xC0, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);

    while(1) {

       GPIOPinWrite(GPIO_PORTD_BASE,GPIO_PIN_7,0x0);

       GPIOPinWrite(GPIO_PORTD_BASE,GPIO_PIN_6,GPIO_PIN_6);

       SysCtlDelay(1000000);

       GPIOPinWrite(GPIO_PORTD_BASE,GPIO_PIN_7,GPIO_PIN_7);

       GPIOPinWrite(GPIO_PORTD_BASE,GPIO_PIN_6,0x0);

       SysCtlDelay(1000000);

    }

Regards

Amit

@Amit

Thanks for the code, I'll check that out.  I now think that there may be an issue with the battery power supply design on my piggy-back board as I can also run the board no problems from a bench power supply.