Cannot capture high-speed GPIOTE interrupts

RE: Cannot capture high-speed GPIOTE interrupts

Edvin — Tue, 21 Dec 2021 20:48:29 GMT

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.

RE: Cannot capture high-speed GPIOTE interrupts

Lin Bencheng — Tue, 21 Dec 2021 14:54:22 GMT

Yes, I tried using SPI peripheral
Yes, I only pick up 1 in 3 events consistently

RE: Cannot capture high-speed GPIOTE interrupts

Edvin — Tue, 21 Dec 2021 14:52:41 GMT

So have you tried using the SPI peripheral?

[quote user="Edvin Holmseth"]Is it consistent that you only pick up 1 in 3 events? Or does it vary?[/quote]

RE: Cannot capture high-speed GPIOTE interrupts

Lin Bencheng — Tue, 21 Dec 2021 14:45:23 GMT

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.

RE: Cannot capture high-speed GPIOTE interrupts

Edvin — Tue, 21 Dec 2021 14:37:27 GMT

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

RE: Cannot capture high-speed GPIOTE interrupts

Mehmet Nuri — Tue, 21 Dec 2021 00:27:53 GMT

Do nothing in interrupt service routine if you dont want to lose data.

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);

}

Do this instead:

void DRDY_pin_handle(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
bool flag = true;

}

//somewhere in your code check for flag like this

if(flag){

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


}

if this is not the issue, you may need to give some detail about your feed line to gpiote pin. Is there a cap for low pass filter or a schmidtt trigger to sharpen the edges and so on.