How to get the correct state of gpio interrupt?

[Ted]

Hi Friend,

My platform is SDK 16 with S140 softdevice.

I set a gpio for edge trigger interrupt. But I cannot get the correct gpio state if the data pulse is too short (maybe 4us to 20us). For example a 5us RF data rising edge generate an interrupt. I get low by my ISR use the function of nrf_gpio_pin_read(TDA5235A_PP1_PIN). Because the pulse is too short. The falling edge interrupt was generated before I read the port state. Like the picture. I have two questions. 1: How to know the interrupt is by falling edge or rising? 2: How to ignore the short pulse interrupt? (Does it can be set the debounce time of interrupt?)

My source code snippet:

uint32_t aaaa[100];
uint8_t bbbb[100];
uint8_t xxxx=0;
void tda5235_sample_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
int32_t counter;
uint8_t last_phrase;

if(lf_rf_task.items.rssi_valid == 1)
{
NRF_TIMER4->TASKS_CAPTURE[5] = 1;
counter = NRF_TIMER4->CC[5];
NRF_TIMER4->TASKS_CLEAR = 1;
if(xxxx<100)
{
aaaa[xxxx]=counter;
bbbb[xxxx]=0;
last_phrase = 1;
if(nrf_gpio_pin_read(TDA5235A_PP1_PIN))
{
bbbb[xxxx]=1;
last_phrase = 0; // current data bit = 1, so last phrase = 0
}
xxxx++;
}
....
}

/**
* @brief Function for configuring: PIN_IN pin for input, PIN_OUT pin for output,
* and configures GPIOTE to give an interrupt on pin change.
*/
static void tda5235_gpio_init(void)
{
ret_code_t err_code;
....

nrf_gpio_cfg_input(TDA5235A_PP1_PIN, NRF_GPIO_PIN_PULLUP);

nrf_drv_gpiote_in_config_t in_config = {
.sense = NRF_GPIOTE_POLARITY_TOGGLE,
.pull = NRF_GPIO_PIN_PULLUP,
.is_watcher = false,
.hi_accuracy = true,
.skip_gpio_setup = false
};

err_code = nrf_drv_gpiote_in_init(TDA5235A_PP1_PIN, &in_config, tda5235_sample_handler);
APP_ERROR_CHECK(err_code);
}

[Edvin]

Hello,

So you are missing some interrupts? Or do you read the wrong state? If you read the pin immediately, you may read the wrong state due to bounce. 

Depending on what your issue is, there would be different approaches.

If you are missing interrupts, and you expect interrupts very rapidly, then I suggest you look into PPI. This would allow you to link events to tasks without including the CPU. This way, you can use a TIMER in counter mode to count the pulses, if you want to measure the pulses. If you want to measure the time, you would use the timer in timer mode instead, and two capture registers to measure the time difference.

If you need to differentiate on the two events HiToLo and LoToHi, you would need to set up two PPI channels. One for each event.

If the issue is that you have some bounce, and the screenshot that you attached is a capture of the bounce that is not intentional, I suggest you look into some method of debounce. Either by using a timer, like the app_button module (not bsp) use. In fact, check out the app_button module. If you expect interrupt really fast, but need to eliminate bounce, you would need a physical debounce (capacitor). However, if you expect the button presses really fast, this will not work.

So, is the screenshot a bounce, or do you want to measure/count these pulses?

[Ted]

The valid data is 104uS +- 30%. The previous screenshot is a bounce. So the bounce generated error interrupts and made me get the wrong state. And I check the data by the two interrupts duration. For example: two interrupts duration is 728uS, it means the data is 7 bits '0' and a bit '1' if next interrupt duration is 104uS. Like the next screenshot. The bounce made me get the wrong data. So I'll find a method to eliminate them.

[Edvin]

What protocol is this? Are you sure you can't use a peripheral to decode it? UART? SPI? Bitbanging (like it looks like you are doing) takes a lot of CPU. It doesn't mix well with BLE, for instance.