• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 411 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.

TM4C129ENCPDT: Interrupt is not getting fired.

Sahil
Expert 1585 points

Part Number: TM4C129ENCPDT

Hi,

Can someone point me out where I am mistaking in my code. 

I have two pins configured for interrupt. The pin on Port M is triggering the corresponding Int-Handler however the Pin on Port N is not triggering its Int-Handler.

Following is the code for PM3 pin which is getting fired.

#define ADC_CTRL_PORT          GPIO_PORTM_BASE

void PM3_interrupt_enable(void)
{
    //Enable Interrupt on ADC_BUSY Pin
    IntMasterDisable();
    GPIOPinTypeGPIOInput(ADC_CTRL_PORT, ADC_BUSY);
    GPIOPadConfigSet(ADC_CTRL_PORT, ADC_BUSY, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU); 
    GPIOIntDisable(ADC_CTRL_PORT, ADC_BUSY);    
    GPIOIntClear(ADC_CTRL_PORT, ADC_BUSY);      
    GPIOIntRegister(ADC_CTRL_PORT, PORTM_Common_IntHandler);
    GPIOIntTypeSet(ADC_CTRL_PORT, ADC_BUSY, GPIO_FALLING_EDGE);         
    GPIOIntEnable(ADC_CTRL_PORT, ADC_BUSY); 
    IntMasterEnable();

}

void PORTM_Common_IntHandler(void)
{
    // Clear the interrupt
    uint32_t status;
    SysCtlDelay(10);
    status = GPIOIntStatus(ADC_CTRL_PORT, true);
    if(status & ADC_BUSY)
    {
        //Do Something
    }

    GPIOIntClear(ADC_CTRL_PORT, status);

}

Following is the code for PN0 pin which is NOT getting fired.

#define DCHRG_CMD_PORT          GPIO_PORTN_BASE

void Enable_DischargePulse_Interrupt(void)
{
    //Enable Discharge Pulse input pin interrupt on ADC_BUSY Pin
    IntMasterDisable();
    GPIOPinTypeGPIOInput(DCHRG_CMD_PORT, DCHRG_CMD_PIN);
    SysCtlDelay(40);
    GPIOPadConfigSet(DCHRG_CMD_PORT, DCHRG_CMD_PIN, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPD);  
    GPIOIntDisable(DCHRG_CMD_PORT, DCHRG_CMD_PIN);        
    GPIOIntClear(DCHRG_CMD_PORT, DCHRG_CMD_PIN);      
    GPIOIntRegister(DCHRG_CMD_PORT, PORTN_Common_IntHandler);
    GPIOIntTypeSet(DCHRG_CMD_PORT, DCHRG_CMD_PIN, GPIO_RISING_EDGE);            
    GPIOIntEnable(DCHRG_CMD_PORT, DCHRG_CMD_PIN);     
    IntMasterEnable();

}


void PORTN_Common_IntHandler(void)
{
    //Clear the interrupt
    uint32_t status;
    SysCtlDelay(10);
    status = GPIOIntStatus(DCHRG_CMD_PORT, true);
    if(status & DCHRG_CMD_PIN)
    {
    //Do Something

    }

    GPIOIntClear(DCHRG_CMD_PORT, status);


}

Thanks for your time and help.

  • 0
    TI__Guru**** 191886 points

    Hi,

      I can't spot anything wrong with your code for portN based on your snippet of code. You have configured for weak pull down for PN0 (based on your comment) and detect for a rise edge on input. Several things to check.

      - Is DCHRG_CMD_PIN mapped to GPIO_PIN_0?

      - Have you created a rise edge on the input?

      - If you place a breakpoint on PORTN_Common_IntHandler, does the processor stop there?

      - Can you try to statically plug the PORTN_Common_IntHandler into the vector table in the startup file instead of using GPIOIntRegister(), does it make a difference?

      Just a heads up, I will be on vacation from 5/8-5/10. My responses will be delayed. 

  • +1
    Expert 1585 points

    Hi thanks for your reply on weekend.

    Yes the DCHRG_CMD_PIN is mapped to correct pin and correct port.

    i am sending a pulse that has both falling and rising edge. Plus I have tried Falling as well as Rising edge with no luck.

    I do have a breakpoint at PORTN_Common_IntHandler and the processor doesn't reach it.

    Can you try to statically plug the PORTN_Common_IntHandler into the vector table in the startup file instead of using GPIOIntRegister(), does it make a difference? Yes i have tried it with no luck. However I am not sure if would have placed it correctly. All i did was replace the default int handle with PORTN_Common_IntHandler next to the corresponding port. Is there any additional step that i might have missed?

  • +1 in reply to Sahil
    TI__Guru**** 191886 points

    Hi,

      I think you are missing the below line for your port N.  Please add the below line and try again. 

    IntEnable(INT_GPION);

  • 0 in reply to Charles Tsai
    Expert 1585 points

    isnt it the same thing as i have GPIOIntEnable() on line 14 in the 2nd snippet of the code ? Please see the 2nd snippet line number 14.

  • 0 in reply to Charles Tsai
    TI__Guru**** 191886 points

    Hi,

      Can you repeat the same problem on a LauchPad?  

    Sahil said:
    Can you try to statically plug the PORTN_Common_IntHandler into the vector table in the startup file instead of using GPIOIntRegister(), does it make a difference? Yes i have tried it with no luck.

     GPIOIntEnable() enables the indicated GPIO interrupt sources (.e.g. GPIO_INT_PIN_0) at the module level. When you plug the interrupt vector statically, you need to also call IntEnable() to enable Port N at the processor NVIC level. 

    Interrupt handlers can be configured in one of two ways; statically at compile time or dynamically at
    run time. Static configuration of interrupt handlers is accomplished by editing the interrupt handler
    table in the application’s startup code. When statically configured, the interrupts must be explicitly
    enabled in the NVIC via IntEnable() before the processor can respond to the interrupt (in addition to
    any interrupt enabling required within the peripheral itself). Statically configuring the interrupt table
    provides the fastest interrupt response time because the stacking operation (a write to SRAM) can
    be performed in parallel with the interrupt handler table fetch (a read from Flash), as well as the
    prefetch of the interrupt handler itself (assuming it is also in Flash).
    Alternatively, interrupts can be configured at run-time using IntRegister() (or the analog in each
    individual driver). When using IntRegister(), the interrupt must also be enabled as before; when
    using the analogue in each individual driver, IntEnable() is called by the driver and does not need
    to be called by the application. Run-time configuration of interrupts adds a small latency to the
    interrupt response time because the stacking operation (a write to SRAM) and the interrupt handler
    table fetch (a read from SRAM) must be performed sequentially.

  • 0 in reply to Charles Tsai
    TI__Guru**** 191886 points

    Hi Sahil,

      Do you have any update?

  • 0 in reply to Charles Tsai
    Expert 1585 points

    Hi Sorry for being late. I marked your comment as the solution. It is now working. Thanks Charles