This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C1294XL: Writing to GPIO PC5

Part Number: EK-TM4C1294XL

I'm using the Enet_s2e application. I need to toggle PC5.

I have the following code at the end of the pinout.c routine to enable the pin:

ROM_GPIOPinTypeGPIOOutput(GPIO_PORTC_BASE, GPIO_PIN_5); 
MAP_GPIOPadConfigSet(GPIO_PORTC_BASE, GPIO_PIN_5, GPIO_STRENGTH_12MA, GPIO_PIN_TYPE_STD);
ROM_GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_5, 0); 

I want to toggle the pin PC5  in SerialSend() each time the telnet receives a character and sends it to the UART for transmission.

GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_5, 1); // U9 TX_EN
UARTCharPut(g_ui32UARTBase[ui32Port], ui8Char);
GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_5, 0); // U9 RX_EN

I can't get activity on the pin PC5 when I monitor it with the scope???

From the TM4C1294XL Data sheet Section 10 p.743, the default state after a PUC is GPIO Input.

I have not configurged GPIOAFSEL for the pin but I'm not certain that the TI supplied SW has not done so somewhere????

  • Gary Armstrong said:
    I can't get activity on the pin PC5 when I monitor it with the scope???

    That's quite true - and in this case - your (obvious) past experience has, "worked against you!"      Your code line:

    Gary Armstrong said:
    GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_5, 1); // U9 TX_EN

    which employs a "1" to (normally) Set a bit - works (only) for GPIO_PIN_0 here!     That final (3rd) parameter is a, "Bit-Packed Byte" - thus requires the unique value of the Bit-Position - to set the targeted bit(s).   For example: GPIO_PIN_7 has the weighted value of 128, GPIO_PIN_5 is 32, GPIO_PIN_2 is 4.    Note that parameter 2 behaves similarly - only those "bits which match" - upon params. 2 & 3  - will "Set."

    When you seek to "Set all Port Bits" (yet NOT upon Port C (JTAG!) parameters 2 & 3 should expand to 255 (0xFF)     (had you chosen GPIO_PIN_0 - then "1" would have "Set that bit" - yet you'd have possibly, "Lost your JTAG Connection in that process."    (software attempts to prevent such - yet such "Loss of JTAG" occurs all too often - well noted on this forum...)

    The remainder of your code appears correct yet the selection of 12mA output drive appears "bit much" for most "normal" applications.     (and will reduce the amount of drive available from "other pins" on that same side of the 4 sided MCU.)     MCU manual details - likely at the very end - under MCU specifications...

  • Excellent, I'll try it in the morning when I get back to work.

  • Excellent on this end as well - your "discovery" has proved "harmless" - surely beating those unfortunate (many) who, "Lock themselves Out" from JTAG... As my group works w/ARM MCUs from several vendors - and each provides a (different) API - we maintain, "Key Code Rules" at each/every work-station - to minimize the inevitable "interference" between different devices.

    I "guarantee" that your "Replacement of "1" w/the proper "Bit-Packed Value" will turn that output ON. (if in fact - it CAN be turned on...)
  • Made the change and still can not get control of PC5??? I'm running Enet_s2e project on the EK-TM4C1294XL Launchpad under FreeRTOS. some other task must have control of PC5????The only change I have made to the program is for control of PC5.
  • Okay, its toggling the bit but its so fast I wasn't capturing it on the scope, my bad :( There is a delay getting char out the TX pin and my enable is negated by that point I need to monitor a UART Busy flag before I negate the TX EN on my line driver.
  • GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_5, GPIO_PIN_5); // U9 TX_EN
    UARTCharPut(g_ui32UARTBase[ui32Port], ui8Char);
    while (UARTBusy(g_ui32UARTBase[ui32Port] ))
    {
    }
    GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_5, 0); // U9 RX_EN
  • Do you believe that (only) your post deserves, "Resolved?"      Appears that the first answering post - rather well - paved your path...

    You may note that when using "symbolic notation" - should you seek to set many bits - your code will often extend onto multiple lines...  (raising the risk of typo/other error)

    Your use of GPIO_PIN_5 indeed supplies the "Bit-Packed Value" required to set that bit.      (as described by the (real) "resolving" post...)     Scope trigger failure should not negate your (proper) award...  (even a "shared award.")

  • Very sorry, I do appreciate your help and obvious great insite. I went back to your post and don't see a away to post it as resolving the problem?

  • If I could figure out how to undo my "This resolved my issue" above, I would. I was assuming this was a way to terminate the thread. I care little about the points. Again thank you for your help.
  • It appears that you've (both) mastered "Post resolved mechanism" and "setting GPIO Output Bits."     Well done & thank you - fare well mon ami...