CCS/LAUNCHXL-F28379D: Configuring External Interrupts

Hi Dan,

Thanks for your question! Would you be able to provide a code snippet of the pin and pad configuration used for GPIO pin 67? For instance, in the C2000Ware example, gpio_ex1_setup.c (located in C2000Ware_*versionnumber*\driverlib\f2837xd\examples\cpu1\gpio):

//
// Make GPIO34 an input on GPIO34
//
GPIO_setPadConfig(34, GPIO_PIN_TYPE_PULLUP);     // Enable pullup on GPIO34
GPIO_setPinConfig(GPIO_34_GPIO34);               // GPIO34 = GPIO34
GPIO_setDirectionMode(34, GPIO_DIR_MODE_IN);     // GPIO34 = input

Please ensure that the pad, pin, and direction are set properly on the pin.

Let me know if you can provide this information from your code, or if the example helps!

Regards,

Vince

Hi Vince,

I have initialized the GPIO pin like this:

GpioCtrlRegs.GPCGMUX1.bit.GPIO67 = 0;

GpioCtrlRegs.GPCMUX1.bit.GPIO67 = 0;

GpioCtrlRegs.GPCDIR.bit.GPIO67 = 0;

Enabled the XINT3 interrupt:

PieCtrlRegs.PIEIER12.bit.INTx1 = 1;

IER |= 0x0800;

Set the Xbar:

InputXbarRegs.INPUT6SELECT = 67;  //Feed GPIO67 to XINT3

I do not think there are other settings to set. Still the interrupt is never entered into. Any support would be appreciated.

Hi Dan,

Thanks for the follow up! Here's a few things to try in debugging this:

• Ensure that the interrupt service routine (ISR) is linked to the particular interrupt you are using. E.g. "Interrupt_register(INT_ECAP1, &ecap1ISR);" where INT_ECAP1 is the ECAP1 interrupt register, and the ecap1ISR is the function that the ISR is linked to.
• Ensure that the GPIO pin locks have been disabled and the internal pullups have been enabled on the GPIO before configuring them.
• Ensure EINT has been called once all configuration of the interrupts is complete.
• Ensure DINT is called before configuring the interrupts (at the beginning of the configuration)

Finally, I would highly recommend starting with the example "gpio_ex3_external_interrupt.c" from the C2000Ware library (latest version of C2000Ware highly recommended):

Location: C2000Ware_*versionnumber*\driverlib\f28004x\examples\gpio\gpio_ex3_external_interrupt.c"

This example may be the exact configuration needed for what you are looking to do, and so will be greatly helpful in developing your software!

The example is meant for the F28004x device, but can be easily ported to other C2000 devices with minor changes.

Let me know if this helps with your debugging!

Regards,

Vince

Hello Vince,

I found the example, thanks. I am using a different code structure than the example but I think I am doing the same things.

I am initializing the GPIOs:

All the pull ups enabled and editing of GPIO settings enabled (disabled after completing the changes).

- GpioCtrlRegs.GPCDIR.bit.GPIO67 = 0;         // GPIO67 is an input (Configured using Input X-Bar to External Interrupt XINT3)
- GpioCtrlRegs.GPCINV.bit.GPIO67 = 1;         // GPIO67 input inverted

I am initializing the Xbar in which I set GPIO67 to Input6 to feed to XINT3:

- InputXbarRegs.INPUT6SELECT = 67;                   // Feed GPIO67 to XINT3, ePWM[TRIP6], EXTSYNCIN2, ePWM X-Bar, Output X-Bar via Input X-Bar

After completing all initializitions, I enabled the interrupt :

    //--- Enable the XINT3 interrupt - GPIO67 is routed using Input X-Bar INPUT6 to XINT3 external interrupt
    PieCtrlRegs.PIEIER12.bit.INTx1 = 1;          // Enable XINT3 interrupt in PIE group 1
    IER |= 0x0800;                              // Enable INT12 in IER to enable PIE group 1

I think it should work like this. I have another interrupt from the CLA continuously working and it works fine.

I am connecting a wire from 3V to GPIO67 to call the XINT3 interrupt while debugging in real time. However, the interrupt routine is never accessed.

Hi Dan,

Thanks for the follow up. My guess is that this has less to do with the configuration/initialization you have chosen and more to do with what is enabled/disabled beforehand, and how the interrupts are prepared for running.

In particular, when setting up the interrupts, can you ensure that "DINT" is called before configuring the interrupt? Can you ensure that you clear the interrupt status after configuring, and ALSO "acknowledge" the interrupt group for GPIO67 after clearing the interrupt status?

Essentially, sequence should be:

• Disable pin locks and enable internal pulups:
  • GPIO_unlockPortConfig(GPIO_PORT_A, 0xFFFFFFFF);
  • GPIO_unlockPortConfig(GPIO_PORT_B, 0xFFFFFFFF);
  • GPIO_unlockPortConfig(GPIO_PORT_H, 0xFFFFFFFF);
• Clear all PIEIER registers
• Clear all PIEIFR registers
• Enable vector fetching from PIE block
• Initialize the PIE vector table with pointers to the shell ISR
• Configure GPIO here (as you've shown in the previous posts)
• Configure XBAR here (as you've shown in the previous posts)
• ***this seems to be missing from what you've mentioned*** LINK THE GPIO ISR TO THE GPIO INTERRUPT REGISTER
  • Interrupt_register(INT_XINT3, &yourISRFunctionNameHere);
• Now you can enable the Interrupt
• Optionally, one additional interrupt clear and re-arm here can be helpful.

Please try the above and let me know if that works.

Also, I would highly recommend trying to load the example program I mentioned and see if it works on your board. If the example program works, then we can use it as a basis to track down the issue in your program.

Regards,

Vince

Hi Vince,

Thanks for the reply. I have managed to enter the interrupt. It looks that it was something to do with the XINT3 enable bit. However I cannot find the interrupt flag to clear for XINT3 when entering the ISR. I am debugging using the Code Composer Studio scripts to debug and enter the ISR in real time and it seems to remain in the ISR sometimes. Is it cleared on its own when the ISR is entered for external interrupts?

Thanks

Hello,

Yes I have acknowledged the interrupt by:

PieCtrlRegs.PIEACK.all = PIEACK_GROUP12;

So is this enough? no flag to clear?

Thanks

Dan

Hello,

Correct, this is enough because by clearing the group, you clear all the respective interrupt flags in that group. Let me know if that answers your question!

Regards,

Vince

Vince Toledo said:

Hello,

Correct, this is enough because by clearing the group, you clear all the respective interrupt flags in that group. Let me know if that answers your question!

Regards,

Vince

Yes, thanks Vince. Highly appreciated.

Hi Dan,

Glad to help! Feel free to open a new thread if you have any additional questions about our devices in your future development!

If I was able to help answer your question, please press the green "Verify Answer" button on the post that solved your issue, thanks!

Regards,

Vince