Radio Activity Causes GPIOTE Interrupt Missing

[Bruce]

Hi,

I'm running a GPIOTE test that pulses a debug pin whenever CPU executes user registered GPIOTE handler. The GPIOTE trigger pin has a 8ms period, 8us duration low-active pulse. Theoretically, the debug pin should pulse the same rate as the trigger. However, whenever I turn on the radio (advertisement / in connection), it causes GPIOTE interrupt to go missing sometimes as you can see in the attached screenshot.

Yellow is the Debug Pin (GPIOTE Interrupt Handler) Blue is generated with ble_radio_notification handler, representing BLE ACTIVE with 800us distance on both ends.

SD: s110_nrf51822_6.0.0-1.alpha SDK: 4.4.2

Not sure if I'm missing anything...

Thanks, Bruce

Code Snippet:

---------------------------------------------
GPIOTE Initialization
=======================
  /* enable negative edge interrrupt on RDY pin */
  nrf_gpio_cfg_input(RDY_PIN_NUMBER, NRF_GPIO_PIN_PULLUP); /* RDY is open drain */
  if ((gpiote_status = app_gpiote_user_register(&gpiote_user_id, 0, 1 << RDY_PIN_NUMBER, &interrupt_handler)) != NRF_SUCCESS)
  {
......
  }

  if ((gpiote_status = app_gpiote_user_enable(gpiote_user_id)) != NRF_SUCCESS)
  {
......
  }

GPIOTE interrupt handler
=======================
static void interrupt_handler(uint32_t event_pins_low_to_high, uint32_t event_pins_high_to_low)
{
  nrf_gpio_pin_set(DEBUG1);
  nrf_gpio_pin_clear(DEBUG1);
}

[Bruce]

Hi Tomoyuki,

I had to write our own GPIOTE driver that utilizes the hardware capture (GPIOTE PIN Event) as opposed to the PORT Events that requires timely CPU intervention. When you use GPIOTE PIN event, there's hardware register that saves the pin status if I'm not mistaken.

Bruce

[Rick.Soza]

Hi Bruce,

Would you be willing to share your GPIOTE driver solution. Seems we're having the same issue. Or walk us through the solution?

Thanks, Rick S