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.

CCS/LAUNCHXL-CC1312R1: The first rising edge triggered interrupt did NOT assert

Part Number: LAUNCHXL-CC1312R1
Other Parts Discussed in Thread: CC1310

Tool/software: Code Composer Studio

Dear Sir,

Profile:

hardware: our custom board with CC1312R1 chip

software: TI simplelink_cc13x2_26x2_sdk_4_30_00_54 sdk with some our patches. (syscfg is frozen)

Problem:

I faced a weird symptom that never occurred on cc1310.

I configured several GPIOs for dip switch input usage. I made them BOTH_EDGES triggered.

However, I always missed the first rising edge interrupt after power on.

(dip switch ON position is low; OFF position is high)

So to speak, if the dip switch pin initial position is ON, I could not catch the first dip position change (i.e. the first interrupt).

Yet, as long as falling edge trigger ever happens on that pin, there is no problem upon  later rising edge interrupts.

Why? How can I debug this issue?

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

GPIO_PinConfig gpioPinConfigs[] = {
....
/* CONFIG_GPIO_DIP0 */
GPIOCC26XX_DIO_01 | GPIO_CFG_IN_NOPULL | GPIO_CFG_IN_INT_BOTH_EDGES,
/* CONFIG_GPIO_DIP1 */
GPIOCC26XX_DIO_11 | GPIO_CFG_IN_NOPULL | GPIO_CFG_IN_INT_BOTH_EDGES,
/* CONFIG_GPIO_DIP2 */
GPIOCC26XX_DIO_12 | GPIO_CFG_IN_NOPULL | GPIO_CFG_IN_INT_BOTH_EDGES,
/* CONFIG_GPIO_DIP3 */
........
/* CONFIG_GPIO_RLED : LaunchPad LED Red */
GPIOCC26XX_DIO_06 | GPIO_CFG_OUT_OD_NOPULL | GPIO_CFG_OUT_HIGH,
/* CONFIG_GPIO_GLED : LaunchPad LED Green */
GPIOCC26XX_DIO_07 | GPIO_CFG_OUT_OD_NOPULL | GPIO_CFG_OUT_HIGH,
/* SPI Flash Slave Select GPIO Instance */
GPIOCC26XX_DIO_20 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_MED | GPIO_CFG_OUT_HIGH,
};

  • Dear Sir,

    In order to avoid any custom board hardware issue, I did a simple test on CC1312R1 launchpad.

    I can reproduce the issue.

    Some key source code as below. I connected a jump line from DIO1 to GND.

    After power up, I remove the GND end (i.e. create rising edge), the interrupt did NOT assert,

    (I set a breakpoint in the callback 'dip_debug_cb'. It was not entered.)

    However, if the initial condition is disconnected (disconnect DIO1 from GND), I can catch

    the first interrupt (i.e. falling edge) when I connected the jump line after power up. 

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

    Button_Params bparams;
    Button_Params_init(&bparams);
    Button_open(CONFIG_BUTTON_0, dip_debug_cb, &bparams);

    ////////////////////////////

    void dip_debug_cb(Button_Handle _buttonHandle, Button_EventMask _buttonEvents)
    {
    CUI_statusLinePrintf(ssfCuiHndl, sensorStatusLine, "buttonEvents=%x",
    _buttonEvents);
    }

    ////////////////////////////

    GPIO_PinConfig gpioPinConfigs[] = {
    ::::::
    /* CONFIG_GPIO_0 */
    GPIOCC26XX_DIO_01 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_BOTH_EDGES,

    }

  • Hi Adam, 

    Which project are you using and what kind of changes have you made to the project? Can you reproduce the issue with the default project from the SDK?

    Thanks,
    Elin

  • Hi Elin,

    In the  later reproduce on cc1312 launchpad, I imported the sensor project which was shown 'sensor_CC1312R1_LAUNCHXL_tirtos_ccs'

    in CCS.

    I patched little,  defining a new button by syscfg tool, adding below code in ssf.c module.

    Button_Params bparams;
    Button_Params_init(&bparams);
    Button_open(CONFIG_BUTTON_0, dip_debug_cb, &bparams);

    ////////////////////////////

    void dip_debug_cb(Button_Handle _buttonHandle, Button_EventMask _buttonEvents)
    {
    CUI_statusLinePrintf(ssfCuiHndl, sensorStatusLine, "buttonEvents=%x",
    _buttonEvents);
    }

  • Hi Adam, 

    Thanks for sharing. 

    Have you debugged using the ROV to see what happens? 

    Thanks, 
    Elin

  • Hi Elin,

    No, I'm not familiar with ROV.

    From my massive test, I think INT_BOTH_EDGES equals to INT_FALLING in behavior.

    Please take a closer look at your side.

    There were a couple of successful trial, but I think it was caused by bounce.

    That is, the falling edge of bounce 'helps'  to assert the interrupt.

    The rising edge does NOT assert the interrupt in the first trigger after boot up.

    BR

    Adam

  • Hi Adam, 

    Can you share the log files from your massive test as well as the modifications you have made to the sensor example? 

    Thanks, 
    Elin