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.

LAUNCHXL-CC1310: CC1310 GPIO interrupt will be enabled automatically after sleep function executed

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310, SIMPLELINK-CC13X0-SDK

Hi, I'm using cc1310 LAUNCHXL for some test. The environment is as follows:

1. SIMPLELINK-CC13X0-SDK 1.40.00 

2. CCS IDE and compiler

3. application: gpiointerrupt example with NORTOS

Before while loop, GPIO_disableInt function has been executed and the gpio interrupt is disabled. But after sleep function executed, I found that the gpio interrupt is enabled automatically. And the gpioButtonFxn0 function will be executed when the button0 pressed. 

The demo is:

----------------------------------------------------------------------------

void *mainThread(void *arg0)
{
GPIO_init();
GPIO_write(Board_GPIO_LED0, Board_GPIO_LED_OFF);
GPIO_setCallback(Board_GPIO_BUTTON0, gpioButtonFxn0);
GPIO_disableInt(Board_GPIO_BUTTON0);
while (1)
{
sleep(5);
}

return (NULL);
}

----------------------------------------------------------------------------

  • Hi,

    is the PIN driver also enabled in your project? Could you try to disable it to avoid any interference? Just don't call Board_initGeneral() nor PIN_init(), but only Power_init() at the start of your main function. Does that solve the problem?

    Do you observe the same problem when working with TI-RTOS?

  • Thanks. It works fine when using only Power_init() at the start of main function.

    Should not the PIN driver and GPIO driver be used at the same time? What's the difference between the two drivers?

    Thanks so much.

  • Hi,

    I am glad to read that it works now. I will create a bug report to our driver team for the example and the driver itself. The reason why we have both, GPIO and PIN driver is unknown to me. I believe, these were 2 different designs contributed by 2 different platform teams used in different products. Probably that's why both ended up in the SDK.