• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 2526 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Generating an interrupt at PORT A PA2 pin

Anand Meharwade
Expert 1090 points
Other Parts Discussed in Thread: LM3S1627

Hi,

For LM4F232H5QD controller on custom board, I am configuring the port A pin PA2 to handle 1PPS interrupt. Currently I am not getting any interrupt at PA2 with following setting. we confirm the voltage of the 1PPS signal and its 3.3volt. 

Following is the code :

******************************************************************************************************************

#define GPIO_PA2_PIN3_GPIO        0x00000800
#define GPIO_PA2_PIN4_GPIO        0x00000C00
#define GPIO_PA2_PIN5_GPIO        0x00001000
#define GPIO_PA2_PIN6_GPIO        0x00001400

void InitGPS1PPSInterrupt(void)
{
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    SysCtlDelay(1);

    HWREG(GPIO_PORTA_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD;
    HWREG(GPIO_PORTA_BASE + GPIO_O_CR) |= 0x3C;

    /*
     * Initialize the GPIO pin configuration.
     * Set pins 2 as input, SW controlled.
     */
    ROM_GPIOPinTypeGPIOInput(GPIO_PORTA_BASE, GPIO_PIN_2);

    ROM_GPIOPinConfigure(GPIO_PA2_PIN3_GPIO);
    ROM_GPIOPinConfigure(GPIO_PA2_PIN4_GPIO);
    ROM_GPIOPinConfigure(GPIO_PA2_PIN5_GPIO);
    ROM_GPIOPinConfigure(GPIO_PA2_PIN6_GPIO);

    /*
     *  set the pins 2 as inputs
     */
    GPIODirModeSet(GPIO_PORTA_BASE, GPIO_PIN_2, GPIO_DIR_MODE_IN);

    /*
     * Make pins 2 rising edge triggered interrupts.
     */
    ROM_GPIOIntTypeSet(GPIO_PORTA_BASE, GPIO_PIN_2 , GPIO_RISING_EDGE);

    HWREG(GPIO_PORTA_BASE + GPIO_O_LOCK) = 0;

    /*
     * Register the port-level interrupt handler. This handler is the first
     * level interrupt handler for all the pin interrupts.
     */
    GPIOPortIntRegister(GPIO_PORTA_BASE, GPS1PPSInterruptHandler);
    /*
     * Clear Any existing Interrupt
     */
    ROM_GPIOPinIntClear(GPIO_PORTA_BASE,GPIO_PIN_2);
    /*
     * Enable the pin interrupts.
     */
    ROM_GPIOPinIntEnable(GPIO_PORTA_BASE, GPIO_PIN_2);
    /*
     *  Enable interrupts on port A
     */
    /*
     * Clear Any existing Interrupt
     */
    ROM_GPIOPinIntClear(GPIO_PORTA_BASE,GPIO_PIN_2);

    ROM_IntMasterEnable();

}

*************************************************************************************************************

Please could any one help me to achieve this task.

Thank you in advance.

Regards,

- Anand M

  • 0
    Guru 47900 points

    Several issues "jump" @ your remote helpers:

    a) Not a comment in sight your unlock code block - (thus we must guess) your recognition is that all pins of Port A default outside of your intent.  Thus you, " HWREG(GPIO_PORTA_BASE + GPIO_O_CR) |= 0x3C;" (liberating Port A PA2-PA5 {past SPI}) . Always good policy to check/insure that your "freed" pin has in fact escaped its default.  And this best done via setting as GPIO Output - and briefly toggling/verifying.  (simple LED serves as adequate test gear)

    b) "ROM_GPIOPinConfigure(GPIO_PA2_PIN3_GPIO);" - Does "GPIOPinConfigure()" really extend to config as GPIO?  When all else fails: SW-DRL-UG works for us (soon, you too) - and reveals:  GPIOPinConfigure(): "This function configures the pin mux that selects the peripheral function associated with a particular GPIO pin."  Confusion here (really could be better detailed w/in that esteemed manual) is that GPIO is not considered a, "peripheral function."  (as normally - unless "special" - most all pins default into GPIO!)  Suspect you're doubtful - review of pin_map.h will reveal not one GPIOPinConfigure parameter - enabling use of that pin as GPIO!  Q.E.D.  Remove all of these "GPIOPinConfigure" function calls.  For GPIO - your use of GPIODirModeSet() should be both necessary and completely sufficient. 

    c) Would not expect an interrupt to be generated w/out:   IntEnable(INT_GPIOA);

    d) and you must declare your Port A interrupt handler properly - w/in your start-up file... (fact not in evidence...)

    Believe these items sufficient to, "bring your Port A interrupt to life..."

    Final point - you were smart & astute enough to discern the need to "free those Port A pins" which defaulted outside your interest.  Yet - code shown engages only 1 pin (PA2) - and this exercise may have been entirely avoided by harvesting any other single pin - from any other Port - not so "default restricted."  Most always best/quickest/easiest to avoid those pins requiring, "special procedures."  Deal w/the exotic only after the basics are well understood...

  • 0
    Guru 86605 points

    Hi,

    Anand Meharwade said:
    HWREG(GPIO_PORTA_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD;

    GPIO_LOCK_KEY_DD - Unlocks the GPIO_CR on Dust Devil Devices not for LM4F232, which is Blizzard class.

    Reference:

    hw_gpio.h

  • 0 in reply to Markel Robregado
    Guru 47900 points

    @Kel:

    We have past used an LM3S1627 (tossed to scrap-heap via NRND proclamation) - it was Dust Devil - thus used "GPIO_LOCK_KEY_DD."   For year + now we've moved to LX4F - and the unlock code is precisely the same - although the _DD suffix is no longer required - but code is the same!

    I present here - definitions from poster's MCU as well as from, hw_gpio.h - as you suggest.  Note - as I mentioned once earlier (same _DD unlock issue) - they are the same!  The _DD suffix is not strictly required - but so long as the compiler recognizes that definition - it will work...

    lm4f232h5qd.h - LM4F232H5QD Register Definitions
    #define GPIO_LOCK_KEY           0x4C4F434B  // Unlocks the GPIO_CR register

    hw_gpio.h - Defines and Macros for GPIO hardware.
    #define GPIO_LOCK_KEY_DD        0x4C4F434B  // Unlocks the GPIO_CR register on DustDevil-class devices and later

    As always - devil in the (fine) details...  (and we should not, "krazy-make" the poster...)

     

  • 0 in reply to cb1
    Expert 1090 points

    Hi cb1,

    Thanks for your reply. Yes its working now after including the InEnable(INT_GPIOA).

    FYI, GPIOPinConfigure(), in this case will disable the SSI function using the macros mentioned in my first post.

    The parameters which you're sending will make difference.

    Thank you very much for your support.

    Regards,

    - Anand M

  • 0 in reply to Anand Meharwade
    Guru 117855 points

    Thank you my friend - glad that you're now, "up/running."

    Be advised that the Port A pins you "liberated" do not require the "Commit Control" procedure - as your code suggests.  Commit Control is mandatory when operating upon any/all of the JTAG pins (PC0-PC3), PD7 & PF0.  But your Port A "re-purpose" may be achieved simply by clearing the corresponding bits W/in GPIOAFSEL & GPIODEN registers.

    I can neither confirm nor dispute your "GPIOPinConfigure()" usage - to "massage" Port A pins from SSI (default) into GPIO.  Suspect the info supplied above is more precise & achieves your objective w/out any "undefined" GPIOPinConfigure paramteter creation/invention.  (if such parameter exists - any document - I could not find and would be interested to learn its existence...)