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?

[osenjw]

Thanks for nudging me towards understanding. I am reading the RM on GPIOTE. The RM is defining the IN[] registers as' IN[0] 0x100 Event generated from pin specified in CONFIG[0].PSEL'.

What is the 'event'? Is it an enumerated value such as LowToHigh or HighToLow? When I end up in the interrupt what should be in the IN[] location?

[osenjw]

I was going to try to flip in the interrupt. If I have a clean signal no problem. But I have the same concern as you, what happens with noise or a true interrupt that is missed? And thanks for clearing my issues with pin vs signal.

I have another question on interrupts. I am used to interrupts that when you end up in the ISR, you need to clear the interrupt flag - or else a subsequent interrupt is not going to happen. Often this is done by just reading the interrupt status register. But with the M0 you actually have to write to the clear interrupt register. Am I reading the RM correctly?

[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.

[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.