Cannot capture high-speed GPIOTE interrupts

Hello, I tried to use pin_change_example in SDK to catch Interrupts (at first line) but I'm missing lots of them.

How can I catch all the interrupt events without delay?
At present, I am using the ble_app_uart template.

This is the code of GPIOTE init and handler functions

void DRDY_pin_handle(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{

//nrf_gpio_pin_toggle(RST2);
drdy_3 = !drdy_3;
nrf_gpio_pin_set(RST2);
__nop();
nrf_gpio_pin_clear(RST2);

}


void ADS127L01_GPIO_Init(void)
{

// Reset OUTPUT Config
nrf_gpio_cfg_output(RST3);
nrf_gpio_pin_clear(RST3);
// Start Output Config
nrf_gpio_cfg_output(START3);
nrf_gpio_pin_clear(START3);
// NCS Output Config
nrf_gpio_cfg_output(NCS3);
nrf_gpio_pin_clear(NCS3);

// GPIO config for testing
nrf_gpio_cfg_output(RST2);
nrf_gpio_pin_clear(RST2);

// DRDY Input Config
// nrf_gpio_cfg_input(DRDY3, NRF_GPIO_PIN_NOPULL);

ret_code_t err_code; // hold error value
err_code = nrf_drv_gpiote_init();
nrf_drv_gpiote_in_config_t in_config = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true); // Falling edge interrupt detection
in_config.pull = NRF_GPIO_PIN_PULLUP;
err_code = nrf_drv_gpiote_in_init(DRDY3, &in_config, DRDY_pin_handle); // Initialize the interrupt pin
APP_ERROR_CHECK(err_code);
nrf_drv_gpiote_in_event_enable(DRDY3, true); // Enable the interrupt events

}

Parents
  • Hello,

    Is it consistent that you only pick up 1 in 3 events? Or does it vary?

    It is fairly quick. What exactly is it you are trying to do? If you are trying to count pulses, I would recommend that you look into PPI + TIMER in counter mode. Especially if you intend to use the Softdevice, which it looks like you are going to since you started with a ble_app_... example. 

    If you don't use PPI, then you may miss a lot of these events, since the softdevice will occupy the CPU from time to time, up to a couple of ms in cases where it has a lot of data to send.

    Best regards,

    Edvin

  • Thanks for your reply
    At present, I am trying to get sensor data via the SPI interface.
    On the sensor side, if data is ready to send, the DRDY pin of the sensor pulse is high to low.
    So I have to read the falling edge of the DRDY pin and start to read data via SPI on the nRF side.
    In this case, I want to get your kind suggestion to handle this issue perfectly.
    As I described I am using BLE_NUS for sending the acquired sensor data.


  • So have you tried using the SPI peripheral? 

    Edvin said:
    Is it consistent that you only pick up 1 in 3 events? Or does it vary?
  • Yes, I tried using SPI peripheral
    Yes, I only pick up 1 in 3 events consistently

  • Perhaps there is something else in your application that is running on a higher or same priority that takes up the time in every 3rd event? Try disabling everything but the pin interrupt and see if it picks up more than 1 in 3 events.

    This being said, if you intend to use the softdevice for Bluetooth, and you want to get all of these events, it will be very tricky using this bit-banging. You will at certain points have the softdevice using the CPU for more than 4µs. As mentioned, up to several milliseconds if you are sending a lot of data. You should consider using the PPI for this. It is a bit tricky to understand at first, but if you like, you can check out the hands-on that I used at some point in time:

    https://github.com/edvinand/ppi_pwm_hands_on

    (solution in the src folder). If you are using the nRF5 SDK, just copy paste the main file into any example from the SDK, remove the printk() and replace the k_sleep() with nrf_delay_ms() (#include "nrf_delay.h").

    PS: We are short staffed due to Christmas Holidays, so we expect some delay in our response time. I will be out of office from tomorrow until the beginning of January. 

Reply
  • Perhaps there is something else in your application that is running on a higher or same priority that takes up the time in every 3rd event? Try disabling everything but the pin interrupt and see if it picks up more than 1 in 3 events.

    This being said, if you intend to use the softdevice for Bluetooth, and you want to get all of these events, it will be very tricky using this bit-banging. You will at certain points have the softdevice using the CPU for more than 4µs. As mentioned, up to several milliseconds if you are sending a lot of data. You should consider using the PPI for this. It is a bit tricky to understand at first, but if you like, you can check out the hands-on that I used at some point in time:

    https://github.com/edvinand/ppi_pwm_hands_on

    (solution in the src folder). If you are using the nRF5 SDK, just copy paste the main file into any example from the SDK, remove the printk() and replace the k_sleep() with nrf_delay_ms() (#include "nrf_delay.h").

    PS: We are short staffed due to Christmas Holidays, so we expect some delay in our response time. I will be out of office from tomorrow until the beginning of January. 

Children
No Data
Related