NRF51422 - GPIOTE PORT events stop being generated - why?

[Martin Ling]

I am encountering a problem with GPIOTE PORT events on the NRF51422 in a custom design. The chip occasionally seems to be able to get into a state in which the registers are set up correctly for a PORT event and interrupt to be generated, but despite this no event occurs.

I have a pin which is connected to a push switch and external pullup resistor, which normally triggers various visible actions on the system. The symptom of the problem is that the system stops responding to the button.

If I hold the switch down when the problem is occuring and then halt the CPU, I can see in the debugger that:

• PIN_CNF is set to input, connected, no pull, standard drive, sense low.
• The IN register for the pin shows the input level as low.
• The GPIOTE INTENSET register shows the PORT enable bit set.
• EVENTS_PORT is zero.

If I set a breakpoint at the GPIOTE interrupt, then:

• With the system working normally, the breakpoint is hit when the button is pressed and shows the registers in the state above, except that EVENTS_PORT reads 1, indicating the event has occured.

• When the problem is occuring, the breakpoint is not hit, and if I halt the CPU I see the registers in the same state as above with EVENTS_PORT reading zero.

I can reproduce this problem on two copies of the board.

What could be preventing this event from being generated?

[Ole Morten]

Unfortunately, as far as I've understood this there is a limitation with the PORT event that requires a deassertion of one pin before it will assert the next. I suspect that is what you're seeing.

Let me try some ASCII-art. Imagine two GPIOs, m and n, both with SENSE set to High. This then shows a sequence of logic levels on those pins:

n: ___|-------------------
m: ____________|----------
      ^        ^
      1.       2. 

1. DETECT signal, which will trigger a PORT event
2. Not a DETECT signal, since it has already been asserted, and the cause has not been cleared.

One workaround for this is to toggle the SENSE field in the GPIOTE_IRQHandler. In that way, the DETECT signal will be deasserted, and 2. above will again assert it, and again trigger the PORT event. This workaround is implemented by app_gpiote in the SDK.

Edit: Replaced app_button with app_gpiote, as this workaround is in fact in app_gpiote.

[Mo A]

Hi OM, What about nRF51822?, I guess the behaviour is the same for both, am I right? regards, Mo