Using two GPIOTE config to a single pin

[osenjw]

In another thread entitled:

Change in GPIO to start/stop timer and fire interrupt

The following code is used:

  NRF_GPIOTE->CONFIG[0] = (GPIOTE_CONFIG_POLARITY_HiToLo << GPIOTE_CONFIG_POLARITY_Pos)
        | (myPin << GPIOTE_CONFIG_PSEL_Pos) // using GPIO 5 as input
        | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);

    //// Configure GPIOTE channel 1 as event that occurs when pin 5 changes from digital
    //// low to hi.
    NRF_GPIOTE->CONFIG[1] = (GPIOTE_CONFIG_POLARITY_LoToHi << GPIOTE_CONFIG_POLARITY_Pos)
        | (myPin<< GPIOTE_CONFIG_PSEL_Pos) // using GPIO 5 as input
        | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);

In the nRF51 RM, there is a statement: Each GPIOTE channel is associated with one physical GPIO pin through the CONFIG.PSEL field...

Is the above code breaking this rule? Are two configurations being mapped to a single pin?

Would the correct code be to look for a change, then check the PIN state in the ISR to determine whether it was HiToLo or LoToHi?

If so, what would be the recommended debounce approach?

[RK]

your problems will start when you are using the softdevice and interrupts get delayed and you miss a flip. This is why I use the same pin in GPIOTE events and hold my nose, it works ok. You can try doing it with a GPIOTE pin toggle event and lots of PPIs, but you soon run out of PPIs, and sanity. You end up with PPIs triggering tasks and other PPIs disabling and re-enabling the first PPIs.

I just changed my board so that the next version will send the same signal to two different pins so I can follow the manual, just to be sure.

And no you don't have to clear the interrupt, the Cortex does that for you, you have to clear the EVENT else that will continue to assert the interrupt which will re-set as soon as the Cortext clears it and put you back there again. GPIOTE->EVENTS_IN[0]=0 before you leave the handler.