[nRF51822] SENSE pin in PORT mode doesn't solve the GPIOTE overconsumption in EVENT mode

Question

The hardware bug #39 on the GPIOTE in EVENT mode which gives a overconsumption of ~1mA even in idle mode on, kills the interest of having a low power chip, because the solution gived by Nordic which is to use the PORT interrupt mode on a pin with SENSE mode enabled, doesn't works when I use multiple interrupts with short transition signals. When I read the NRF_GPIO->IN, the signal may have has already gone down because I have lost some interrupts occurences. 
 Could you please recommend another way to deal with interrupts, still staying in low power ?
Thanks,

Stefan Birnir Sverrisson · Accepted Answer

Hi 
 Yes you are correct, using the GPIOTE->IN events is high current. For low power applications, you should use the app_gpiote library to use the GPIOTE->PORT event most efficiently and is very low power. The functionality is as follows: 
 
 When a pin is pressed a PORT event is
generated which will trigger the
GPIOTE interrupt. 
 When the GPIOTE interrupt handler is
entered, the PORT event flag is
cleared, enabling another pin
interrupt to be detected by the PORT
event. 
 Pin sensing can be enabled on low
signal sensing, high signal sensing,
or both. The safest way is register
for both high and low signal sensing,
then if a button is pressed, and a
second button is pressed before the
PORT event is cleared, then you can
detect when the second button is
released. 
 If the second button is pressed and
released before the PORT event is
cleared, you will miss the button
press of the second button. 
 If the softdevice is not used, it
should be adequate to set and hold a
pin signal for 10 us to guarantee
that the application will receive an
event for the pin signal. The
priority of the GPIOTE_IRQHandler is
APP_IRQ_PRIORITY_HIGH (priority level
 
 so if the application does not set
other interrupts to the same priority
or higher, then 10us should be fine.
You must register for an event on
both high and low signal transition. 
 
 
 If the softdevice is used, the pin
signal must be held for 2ms during
advertising and 0.8-6.0 ms during
connection (depends on how much data
is sent over the BLE link in each
connection event. 0.8ms when no
payload data is transmitted, 1ms when
transmitting one packet and 6ms when
transmitting 6 packets) This is
because the softdevice will block the
CPU during radio transmission, and
the PORT event can not be cleared
when the CPU is blocked. 
 With the upcoming third revision hardware for 
the nRF51, the CPU constraint during
radio event is somewhat releaved, both for advertising and when the nRF51 is in a connection. The
signal on a button needs to be held
for 250us to guarantee that a button
press is detected when the softdevice
is enabled and when detecting a signal change both on rising and falling edge with the app_gpiote library. 
 To detect button presses when the
button is pressed by a human, the
best choice is to use the app_button
library, which is used by many ble
examples in the SDK, e.g. the
ble_app_bps example. If the pin signal
is however generated by an external circuit/MCU,
it is suitable to use the app_gpiote
directly. 
 The app_button
library uses the app_gpiote library
in the background. App_button library adds a debounce
function, where the button press is
actually detected some milliseconds
after the button is pressed
(configurable).

[nRF51822] SENSE pin in PORT mode doesn't solve the GPIOTE overconsumption in EVENT mode

Top Replies