TM4C123GH6PZ: Facing problem in PORTF functioning

Hi Kunal,

Kunal Mahajan said:

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

     Wrong unlocking code for PF0. Search again in the forum. The unlocking code should be part of your initialization at your main().

-kel

Hi,

just a suggestion. TI have made a PinMux utility that will generate the code you need for this. Just select the right mcu and select the function for your pins. The the software will make the C files for you, including the unlocking function (and most of the time it will actually work).

http://www.ti.com/tool/tm4c_pinmux

Best regards

For the record - we've noted that "over-reliance" on such, "effort/understanding-lite" tools (such as pinmux) - may have the unwanted effect of retarding the focused study to fully/properly harness the power/capabilities of these complex MCUs.

PF0 is flagged/highlighted, several times w/in the MCU manual, (although not sufficiently - to many minds) and the "miss" of that fact usually signals inadequate "read/review" of the MCU manual - necessary for any real success w/these devices...

Believe the use of "crutch" AND fair manual read/review is the best path to success.

Hello Kunal,

The issue is in

HWREG(GPIO_PORTF_BASE + GPIO_O_AFSEL) |= 0x400;

Since the AFSEL is already set OR-ing it with 0x400 would result in the bit remaining set and not available for GPIO. You need to do the following

HWREG(GPIO_PORTF_BASE + GPIO_O_AFSEL) &= 0xFE;

to clear the AFSEL bit.

Regards

Amit

Thank you markel and all,

I have corrected the mistake just after my post and I got the result that i can toggle the pin and i have also enabled

peripheral for that port .

But thanks for support,

I have one more query that am using PD0 to PD7 for LCD data connections but there i did not unlock the PD7 pin but

it still working then why so?

Hello Kunal

What is value of the Commit Register for Port D. If bit 7 of the register is 1 then it can be changed without unlocking

Regards

Amit

@Amit,

Amit Ashara said:

HWREG(GPIO_PORTF_BASE + GPIO_O_AFSEL) &= 0xFE;

I guess the unlocking code for PF0 at ButtonsInit(), is not up to standard, as it does not have GPIOAFSEL code line above. See, below.

void
ButtonsInit(void)
{
    //
    // Enable the GPIO port to which the pushbuttons are connected.
    //
    ROM_SysCtlPeripheralEnable(BUTTONS_GPIO_PERIPH);

    //
    // Unlock PF0 so we can change it to a GPIO input
    // Once we have enabled (unlocked) the commit register then re-lock it
    // to prevent further changes.  PF0 is muxed with NMI thus a special case.
    //
    HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(BUTTONS_GPIO_BASE + GPIO_O_CR) |= 0x01;
    HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = 0;

    //
    // Set each of the button GPIO pins as an input with a pull-up.
    //
    ROM_GPIODirModeSet(BUTTONS_GPIO_BASE, ALL_BUTTONS, GPIO_DIR_MODE_IN);
    ROM_GPIOPadConfigSet(BUTTONS_GPIO_BASE, ALL_BUTTONS,
                         GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);

    //
    // Initialize the debounced button state with the current state read from
    // the GPIO bank.
    //
    g_ui8ButtonStates = ROM_GPIOPinRead(BUTTONS_GPIO_BASE, ALL_BUTTONS);
}

-kel

Hello Kel,

Having the CR bit set is sufficient. Once the CR bit is set then AFSEL, DEN, and other controls can be modified. Having the same set in the UNLOCK-LOCK sequence is not mandatory.

Regards

Amit

Amit Ashara said:

Having the CR bit set is sufficient.

@Amit. Yes, it is mentioned in the datasheet.

There are lots of posts in the forum regarding "unlocking code". I don't think that all people participating in those posts knew that "setting the CR bit is sufficient".

-kel

Hello Kel,

I can understand that this information exists in Feature Definition and the Register definition. I think the user should read the sections of the data sheet while we try to make this information better in the next rev of the data sheets.

Regards

Amit