External interrupt issue

Hi Milan,

This has been identified as an issue and will be corrected in the future release. For Home Automation -1.2 and previous releases. 

Interrupts may be missed when used as wake up source or wake up interrupts. The GPIOs have two separate configurations: as generic interrupts, and as power-up interrupts (i.e. wakeup sources from sleep): These are enabled using the registers GPIO_IE and GPIO_PI_IEN respectively. (please see the CC2538 user’s guide: http://www.ti.com/lit/ug/swru319b/swru319b.pdf). The status of each of the interrupt type (i.e. which source triggered the interrupt) is also available separately, via GPIO_MIS for the enabled general interrupts, and GPIO_IRQ_DETECT_ACK for enabled power interrupts. 

Both type of interrupts triggers the same interrupt handler, which is registered in the interrupt vector. This direct interrupt handler is a single function that is called for all the GPIOs of the same port. This handler, in turn, checks to see which specific GPIO triggered it, and calls a specific handler. 

In the code, this ‘direct’ interrupt handler for all PortA GPIOs is ioPortAIsr() ( download the source code from http://www.ti.com/tool/cc2538-sw and the project at install-dir\bsp\srf06eb_cc2538\drivers\projects\iar)  you can see the bsp project file io_pin_int.c for this ). To determine the actual GPIO that triggered the interrupt, it reads GPIO_O_MIS (i.e. the indication of the triggered general-interrupts). The issue seems to be that sometimes while the device is asleep, a button-press successfully triggers a power-interrupt, but fails to trigger the respective normal interrupt. So, ioPortAIsr() is called (since triggered by the power-interrupt), but when it checks which GPIO caused the interrupt it sees none. Then it finishes without doing anything, and immediately called again since the power interrupt is never cleared. Pressing the button again at this time will be successfully caught as a general interrupt, and release the loop: ioPortAIsr() will check the sources again, will see this button was pressed, and will call the respective GPIO-specific interrupt handler - in our case interrupt_keybd(), which call SysCtrlPowIntClear() that clears the power-interrupt signal. 

A minor modification to the deiverlib code is required to resolve this. The respective source code may be downloaded from http://www.ti.com/tool/cc2538-sw. After downloading the source package from the link above, please add to the IAR project all the C files from swrc271a\cc2538_foundation_firmware_1_0_1_0\driverlib\cc2538\source. Please also remove the ‘driverlib’ library from the linker list, in project->options->linker->Library. 

Then, in gpio.c, modify GPIOPinIntStatus() as follows: 

GPIOPinIntStatus(uint32_t ui32Port, bool bMasked) 

{ 

    // 

    // Check the arguments. 

    // 

    ASSERT(GPIOBaseValid(ui32Port)); 

    // 

    // Return the interrupt status. 

    // 

    if(bMasked) 

    { 

        return(HWREG(ui32Port + GPIO_O_MIS) | GPIOPowIntStatus(ui32Port,bMasked)); 

    } 

    else 

    { 

        return(HWREG(ui32Port + GPIO_O_RIS) | GPIOPowIntStatus(ui32Port, bMasked)); 

    } 

} 

Doing these changes should resolve the issue of missed interrupts when the GPIO is used for both power up and normal interrupts. 
Regards,