• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 33 subscribers
  • Views 1322 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C1294NCPDT: GPIO issue : impossible to set some output pins

Sylvain Monsalve9
Prodigy 20 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Dear technical support team,

I have some difficulties to use as GPIO PM1, PG1, PK4 and PK5 pins on my EK-TM4C1294XL launchpad.

I use the same code for the PM0 pin that works correctly :

#define VO_SER_GPIO_PORT_BASE GPIO_PORTM_BASE
#define VO_SER GPIO_PIN_0
#define VO_SRCLK_GPIO_PORT_BASE GPIO_PORTG_BASE
#define VO_SRCLK GPIO_PIN_1
#define VO_RCLK_GPIO_PORT_BASE GPIO_PORTK_BASE
#define VO_RCLK GPIO_PIN_4
#define VO_OE_GPIO_PORT_BASE GPIO_PORTK_BASE
#define VO_OE GPIO_PIN_5
#define VO_SRCLR_GPIO_PORT_BASE GPIO_PORTM_BASE
#define VO_SRCLR GPIO_PIN_1

/* System clock initilisation here */

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOH);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOK);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOL);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOM);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPION);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOP);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOQ);

MAP_GPIOPinTypeGPIOOutput(VO_SER_GPIO_PORT_BASE, VO_SER);

MAP_GPIOPinTypeGPIOOutput(VO_SRCLK_GPIO_PORT_BASE, VO_SRCLK);

MAP_GPIOPinTypeGPIOOutput(VO_RCLK_GPIO_PORT_BASE, VO_RCLK);

MAP_GPIOPinTypeGPIOOutput(VO_OE_GPIO_PORT_BASE, VO_OE);

MAP_GPIOPinTypeGPIOOutput(VO_SRCLR_GPIO_PORT_BASE, VO_SRCLR);

MAP_GPIOPinWrite(VO_SER_GPIO_PORT_BASE, VO_SER, 1);

MAP_GPIOPinWrite(VO_SRCLK_GPIO_PORT_BASE, VO_SRCLK, 1);

MAP_GPIOPinWrite(VO_RCLK_GPIO_PORT_BASE, VO_RCLK, 1);

MAP_GPIOPinWrite(VO_OE_GPIO_PORT_BASE, VO_OE, 1);

MAP_GPIOPinWrite(VO_SRCLR_GPIO_PORT_BASE, VO_SRCLR, 1);

 

With this code only the data register bit (bit 0 of the GPIODATA regrister) corresponding at the PM0 pin works correcly.

Do you have some ideas to help me ?

With best regards

Sylvain

  • 0
    Guru 13040 points

    Sylvain,

    This is wrong:

    MAP_GPIOPinWrite(VO_SRCLK_GPIO_PORT_BASE, VO_SRCLK, 1);

    The third parameter on a GPIOPinWrite should be a mask containing the bits you want to write to the pins defined by the 2nd parameter. It is NOT a "0" to turn off and "1" to turn on. The value "1" corresponds only to GPIO_PIN_0.

    In other words, always repeat the pin:

    MAP_GPIOPinWrite(VO_SRCLK_GPIO_PORT_BASE, VO_SRCLK, VO_SRCLK);

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    While "repeating" the "parameter values" between parameters 2 & 3 will work - there is NO requirement to do so, "always."      (unless "carpal tunnel" is sought...)

    Instead, employing the "Bit Position Value(s)" w/in parameters 2 & 3 (which may range from "0 to 128" (for single bits)) also works - and avoids "endless" extension of the function when multiple bits (especially when ALL bits) are to be set ON!    (wake me - when that task completes)

    It is my belief that the second parameter is the "mask" (controls which GPIO pins (may) be output - thus "masks") and that parameter 3 - when "reflected w/in param. 2" - outputs those bits "common" to both params: 2 & 3.     (thus both params: 2 & 3 may range from 0 - 255, w/255 (potentially able to turn ON ALL of the Port's bits...while "0" quiets the entire Port.)

  • 0 in reply to cb1_mobile
    Guru 13040 points

    A more pragmatic approach:

    Parameter 2: mask for the pins that are allowed to be changed by this command.

    Let's say GPIO_PIN_2 + GPIO_PIN_3 (00001100)

    Parameter 3: set of 8 bits containing the values (LOW's or HIGH's) that those pins on Param2 are to assume.

    Let's say GPIO_PIN_3 + GPIO_PIN_7 (10001000)

    In this case, the Write command will turn GPIO_PIN_2 OFF/LOW and will turn GPIO_PIN_3 ON/HIGH. Pin 7 is present on the mask of Param3, but is "not allowed to be touched" for it is not on Param2, hence it will not change the previous status.

    In case of a lazy approach, this will turn the 2 pins ON without much thinking:

    #define GPIO_PIN_TURNON 0xFF // (11111111)
GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2 + GPIO_PIN_3, GPIO_PIN_TURNON);

    Not sure how useful that would be, but, well...

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    I stand by the belief that (only) param. 2 serves as, "Mask."

    As justification - consider the case where param. 2 is "0xFF." That (potentially) enables ALL bits included w/in param. 3.    Now - should param. 2 change to "0xFE" - param. 3 is, "Unable to set Bit 0" even when param. 3 is loaded w/ "0xFF."      (thus - legally & convincingly - param. 3 FAILS as a mask!)

    Param. 2 is dominant - review of the code should reveal that, "only those bits addressed by param. 2" - are "considered" for output - when they appear w/in param. 3.

  • 0 in reply to cb1_mobile
    Guru 27665 points

    According to the manual param 2 is the mask and param 3 the value as you say.

    However, that said I don't find using the full values for both much of a burden, cut and paste is quite effective. Even in the event I didn't use the full set of bits orred together I wouldn't use the naked 0xFF.

    #define ALL_PORT_BITS_ON (0xFFu)

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Thank you - one here first called "Param. 3 (the) Mask" - then moved to (both) 2 & 3 - yet (only) param 2 - serves that key role...

    We don't need no "manual" (or badges!)   ...   (or "N/C" MCU pins - good grief!)

  • 0 in reply to cb1_mobile
    Prodigy 20 points

    Dear all,

    Thanks to your help I manage to drive correcly the GPIO pins.

    I read too quickly the user's manuel, Sorry !

    With best regards,

    Sylvain

  • 0 in reply to cb1_mobile
    Guru 13040 points
    It came to my attention that the word mask has been improperly applied in a previous explanation, which has now been edited.
  • 0 in reply to Bruno Saraiva
    Guru 117855 points
    Re: "came to ... attention" - may be better described as, "Attention was directed to..." (proper attribution)
    Note the post in receipt of (past) Verify (which you deserved!) continues the (mistaken) claim of Param. 3 as "mask" - which it is NOT!