GPIOTE problems

[Frank]

Hi,

My SDK version:9.0 SD:8.0

I use gpiote to generate an interrupt,

static void bma255_int_hook(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
  g_int1_triggered = true; 
}

uint32_t bma255_int_pin_set(void)
{
  uint32_t	err_code;
  if (!nrf_drv_gpiote_is_init())
  {
    err_code = nrf_drv_gpiote_init();
    if (err_code != NRF_SUCCESS)
    {
       return err_code;
    }
  }

  nrf_drv_gpiote_in_config_t config = GPIOTE_CONFIG_IN_SENSE_HITOLO(false);
  config.pull = NRF_GPIO_PIN_PULLUP;
    
  err_code = nrf_drv_gpiote_in_init(BMA255_SPI_INT1, &config, bma255_int_hook);
  if (err_code != NRF_SUCCESS)
  {
      return err_code;
  }
  nrf_drv_gpiote_in_event_enable(BMA255_SPI_INT1, true);
  return NRF_SUCCESS;
}

But the interrupt cannot be generated, then I capture the waveform from the oscilloscope

The graphs show the interrupt signal can be captured, and it keeps for more than 200us. but the ISR (bma255_int_hook) cannot be executed.

Then I changed the interrupt configuration,

GPIOTE_CONFIG_IN_SENSE_HITOLO(false) --> GPIOTE_CONFIG_IN_SENSE_HITOLO(true)

The ISR (bma255_int_hook) finally can be executed.

True : hi-accuracy false : low-accuracy

However, the current in case "true" is much higher (above 1mA) than "false"(100uA)

The question is, how can the ISR be executed and the current be lowered? Thank you!

[Stefan Birnir Sverrisson]

Hi

Make sure the gpiote interrupt priority is set to high, i.e. that APP_IRQ_PRIORITY_HIGH is set for GPIOTE in the nrf_drv_config.h file.

The current consumpion difference you see is normal. Current consumption when using high accuracy is ~1mA, while the low accuracy gpiote uses <1uA. When using low accuracy, the GPIOTE PORT event is used. The PORT event does not know which pin caused the interrupt, but needs to check the status of pins in the interrupt handler to conclude what pin caused the interrupt. If the CPU is blocked by a higher priority interrupt, e.g. BLE interrupt when the signal occurs, then the GPIOTE interrupt handler in the nrf_drv_gpiote does not detect any pin signal, and the application interrupt is not called. BLE interrupts can block the CPU up to 500us, and therefore potentially delay the GPIOTE interrupt by 500us. If you have another interrupt executing at high priority as well, that will also block execution of the GPIOTE handler.

You could check if the nrf_drv_gpiote driver actually gets the GPIOTE port interrupt by placing a breakpoint at the beginning of the GPIOTE_IRQHandler.

[Stefan Birnir Sverrisson]

For further explanation, check the discussion on this thread. I find it strange though that you do not detect any interrupt when using the GPIOTE PORT event. If you have softdevice enabled, you could miss an interrupt once in a while but not all the time, as BLE events are periodic but not constant.