RE: Nrf51822 stops handling GPIOTE->PORT interrupts

Hung Bui — Wed, 15 Nov 2017 10:22:33 GMT

@sansei: Please be aware that the DETECT signal is shared between all pins. Meaning if one pin is keeping the DETECT signal high, it will block the GPIOTE PORT even to trigger again by other pins.

With your setup, I don't see how you can handle the scenario where the button is pressed at the point that you are processing the SENSOR, it will keep the DETECT signal high, and blocks the GPIOTE PORT event to be triggered. This mean the button press will never be handled and if the SENSOR is triggered again, it will too, won't be processed by the CPU. The result is a deadlock and you will see that the device won't respond to the button press to reset.

So basically, a PORT even can only be triggered if all of the triggers (GPIO pin with SENSE enable) are inactive. You will have to either do a loop to wait and process all the pin before you clear the event NRF_GPIOTE->EVENTS_PORT = 0; or you have to invert the SENSE polarity so that the holding pin won't hold the DETECT signal any more.

Another option is to use GPIOTE PIN event, so that they don't share the same DETECT trigger, but current consumption of GPIOTE PIN is much higher than GPIOTE PORT.

RE: Nrf51822 stops handling GPIOTE->PORT interrupts

AmbystomaLabs — Tue, 14 Nov 2017 23:22:05 GMT

You should say which SD if any you are using.

Also, I'm not really crazy about those nrf_delay statements. The delay routine literally holds the processor up running NOP's until the delay is over. It is a huge waste of power (significant if battery operated) and also could cause issues with the queuing of ISR's. If you are running the SD there are many tasks that require ISR's and you could simply be overflowing the NVIC. A better way to keep LED's on. or do some other delay is to use the app_timer.