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

[boby]

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]

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
  1. 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).

[leppie]

Hi, do you have a rough indication when the 3rd hardware revision will be available? 250us would cover my timing requirement, but 2ms during advertising might be tricky to deal with. Another option would have been if the RTC supported input capture, but according to the spec it does not. Thanks.