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]

The event is whatever is configured in CONFIG[0]'s bitmask, which includes whether the GPIOTE is set for TASK or EVENT, you want EVENT, what the pin is, what the transition is (that's a bitmask) and OUTINIT which you don't care about, because that's for TASKS.

When the given transition occurs on the given pin, that EVENT triggers. At that point the model is the same for any other EVENT in the system, eg CLOCK has an HFCLKSTARTED event, in this case you have an array of IN events. So GPIOTE->EVENTS_IN[0] == 1 and if you have the interrupt set to fire, it will fire. You have to clear that EVENTS_IN[0] back to 0 before you exit the interrupt handler, or it will fire again.