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.

[Martin Ling]

I am already using the app_gpiote module, which toggles SENSE in the GPIOTE_IRQHandler as you describe.

I'm not using app_button since I had different requirements, but there is no such workaround in app_button, the app_button module just assumes that app_gpiote is working correctly.

The situations that seem to trigger this problem are ones where several GPIOs may change in succession (in particular, I get it when USB power is removed from my device and various signals from the USB and power management chips all change together or in close succession).

I had previously reviewed the app_gpiote code suspecting a race condition, and concluded from my understanding of the hardware at that time that the code should be OK, because even if the SENSE levels got out of sync with the pin states, a new event would just be generated and the ISR would be repeated.

If you are telling me however that the PORT event is edge-triggered from the DETECT signal rather than level-triggered, then there is a race condition here.

The sequence of events is as follows:

1. Pin set to sense high.
2. Pin goes high, DETECT asserted, PORT event set.
3. GPIOTE_IRQHandler called
4. GPIOTE_IRQHandler clears PORT event.
5. GPIOTE_IRQHandler reads IN register.
6. GPIOTE_IRQHandler sets SENSE level according to value read from IN.

If the pin goes low at any time after step 2 and before step 5, then the SENSE level will not be changed from its previous value and the DETECT signal will remain asserted, allowing no further PORT events to be generated.

When multiple signals are being monitored the problem becomes only more likely, because any of them can change in this window and cause DETECT to remain asserted.

What troubles me is that with no way to read the DETECT signal from the CPU, I cannot even readily see how this can be fixed. It seems like a fundamental flaw in the design.

[Martin Ling]

Sorry, the above sequence is in't it - the GPIOTE_IRQHandler in app_gpiote reads IN before it clears the PORT event. I am trying to work out if there is an alternative race.

[Martin Ling]

I believe I have now identified the race in the app_gpiote ISR which triggers this problem. It requires at least two pins to be involved. The sequence is as follows:

1. Initially, pins A and B are both low, and are set to sense high. The DETECT signal and PORT event are both deasserted.

2. Pin A goes high, the DETECT signal is asserted, and the PORT event bit is set.

3. The GPIOTE ISR is triggered, and reads the IN register which shows A high and B low.

4. Pin B goes high.

5. The GPIOTE ISR sets Pin A to sense low, and B to sense high. Because B is already high, the DETECT signal remains asserted.

The ISR is trying to force the DETECT signal to be deasserted by setting all the pin sense levels to the opposite of the current input. This can never be reliable because the input can always change between reading the IN register and writing the new SENSE settings.

I believe the solution is to first set SENSE to disabled on all pins, before writing the new SENSE settings. This will force the DETECT signal to be deasserted. If the inputs have changed before the new SENSE settings are written, DETECT will be then re-asserted when the new settings are applied. This will trigger a new PORT event and the ISR will then be re-entered to deal with the new change.

I will make this change to the app_gpiote ISR and see if it resolves the problem here. If so I will post a patch.

[Ole Morten]

I agree on you line of thought, but when I'm testing this, I'm not able to generate a lockup, only losing the second interrupt. If I add a delay a in the IRQ handler between reading IN and toggling SENSE, and then toggle two pins with an interval b < a, I see that most often only the first toggle is detected.

Have you been able to consistently get this to fail? If so, could you share the project you've been working with? Also, did you get anywhere with a workaround?