Current consumption when using rtc, ppi and gpiote

Hi Sir/Madam

I wrote a small program for low current verification on nrf51822 development kit with starter mother board. The program is based on "blinky_example" project configuration. It is doing gpio pin 24 toggling by using rtc, ppi and gpiote modules. However, the voltage reading from connector K2 is about 120mV or 1200uA at P7 even the CPU is called "__WFI" and unplugged the Jlink. From my understanding, CPU can operate below 5uA when it is sleep. Or ppi module is already used 1mA? Or something wrong on the code. Thanks a lot.

#define LFCLK_FREQUENCY          (32768UL)             /*!< LFCLK frequency in Hertz, constant */
#define RTC_FREQUENCY             (8UL)                     /*!< required RTC working clock RTC_FREQUENCY Hertz. Changable */
#define COMPARE_COUNTERTIME       (1UL)            /*!< Get Compare event COMPARE_TIME seconds after the counter starts from 0 */

#define COUNTER_PRESCALER         ((LFCLK_FREQUENCY/RTC_FREQUENCY) - 1)  /* f = LFCLK/(prescaler + 1) */

void ppi_init(void)
	// Configure PPI channel 0 to start ADC task	
	NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RTC0->EVENTS_TICK;	
	NRF_PPI->CH[0].TEP = (uint32_t)&NRF_GPIOTE->TASKS_OUT[0];

	// Enable PPI channel 0
	NRF_PPI->CHEN = (PPI_CHEN_CH0_Enabled << PPI_CHEN_CH0_Pos);

static void rtc_config(void)
	NRF_RTC0->PRESCALER = COUNTER_PRESCALER;                   // Set prescaler to a TICK of RTC_FREQUENCY
	// Enable TICK event and TICK interrupt:

static void lfclk_config(void)

 * main() function
 * @return 0. int return type required by ANSI/ISO standard.
int main(void)

        // Configure the GPIOTE Task to toggle the LED state.

    // Enter main loop
    for ( ; ; )

  • I asked about this too, but have not received a reply from Nordic Semi. See:

    My impressions is that there may be a hardware bug causing the CPU not to go to sleep properly when using GPIOTE. Even my minimal program with only one line of code that only enables GPIOTE causes too high current use:

    (GPIOTE_CONFIG_MODE_Task *shiftleft* GPIOTE_CONFIG_MODE_Pos)     |
                                             ((uint32_t)outPin *shiftleft* GPIOTE_CONFIG_PSEL_Pos)     |
                                             ((uint32_t)NRF_GPIOTE_POLARITY_TOGGLE *shiftleft* GPIOTE_CONFIG_POLARITY_Pos) |
                                             ((uint32_t)NRF_GPIOTE_INITIAL_VALUE_HIGH *shiftleft* GPIOTE_CONFIG_OUTINIT_Pos);

    Please Nordic Semi, can you confirm this problem, and hopefully give a work-around!

  • Thanks for your information. I re-check my code, as u said the current seems drawn from gpiote "nrf_gpiote_task_config". However, the current consumption of gpiote block is 0.1uA in output mode and 100uA even it's in in input mode. (nRF51822 Product Specification v1.3 section 8.10 GPIOTE specifications).

  • Hi Nordic, since my application need work in low power condition with pin toggling. Do you have any idea on high current drawn from gpiote? Is it normal or some kind of hardware issue? Thanks a lot.

  • Did you contacted nordic directly? they tell you something about it?

  • Hi

    The GPIOTE IN events and OUT tasks have had current consumption issues both for our first revision hardware and the current second revision hardware. We have recommended not to use it for low current applications. The reason was that the high frequency 16MHz clock is always enabled while the GPIOTE IN events or OUT tasks are enabled, consuming about ~1mA of current.

    Until now, use of the GPIOTE IN events have been avoided by using the GPIOTE PORT event instead, which is very low current (<1uA). The port event however does have a drawback because it does not know from which pin the interrupt was generated. However, the app_button library uses the PORT event and compensates for its drawback. The GPIOTE OUT tasks have however not been usable until now for low current applications.

    The third revision hardware of the nRF51 has a solution for the GPIOTE OUT tasks, which has very low current consumption (<1uA). The third revision nRF51 hardware will be released in a few days. The third revision hardware still does not have a solution for the GPIOTE IN events, they still consume high current, so for low current applications, use the GPIOTE PORT event instead or the app_button libary.