GPIOTE interrupts missed?

[rolandash]

Hi,

I am testing GPIOTE interrupts on 833, and noticed the interrupt is not fired sometimes (randomly) on power up. The input level did change as measured but the interrupt is not seen. I am not quite sure the reason behind yet, but I would like to clarify few questions first:

1. I have configured GPIOTE like following

    nrfx_gpiote_in_config_t in_config = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true);

so when the input level changes, is the interrupt edge triggered or level trigged? 

2. is there requirement/limitations on the rate of level changes? If put in extreme case, that the input level slope is very slow from high to low (like 50~100ms), will the interrupt be fired in the end?

Thank you.

[Einar Thorsrud]

Hi,

As you specify true with NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO, you use GPIOTE, and the interrupt will be edge triggered. As you write that this issue only happens during startup I wonder if there could be something timing related here, for instance that the transition sometimes happens before the input pin with interrupt is enabled?

Also, if the transition is as slow as you write, perhaps it would make more sense to use a comparator (COMP/LPCOMP) instead of GPIOTE?

[rolandash]

Thank you  Einar Thorsrud  for the quick reply in holiday season!

Below is my initialization code to config GPIOTE interrupt, quite straightforward I think

    nrfx_gpiote_in_config_t in_config = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
    //in_config.pull = NRF_GPIO_PIN_PULLUP;
    ret_code_t err_code;
    if(!nrfx_gpiote_is_init())
    {
        err_code = nrfx_gpiote_init();
        APP_ERROR_CHECK(err_code);
    }
    err_code = nrfx_gpiote_in_init(DT_IO_EXP_INT_PIN, &in_config, &dt_tec_io_exp_irq_handler);
    APP_ERROR_CHECK(err_code);
        
    nrfx_gpiote_in_event_enable(DT_IO_EXP_INT_PIN, true);
    
    //Check if already an INT from input, before we set everything up.
    uint8_t int_pin_val = nrf_gpio_pin_read(DT_IO_EXP_INT_PIN);
    
    //and value of int_pin_val is 1 as measured (3.3V)

According to my profiling, the enabling of GPIOTE event got executed at about 2ms after power up. And immediately after the enabling, the read of the int pin always printed out of 1 (also confirmed by measuring 3.3V). 

The input level change to low happens around 50ms after power up, also confirmed by measuring a 0V. Theoretically for whatever happens in between the time gap and the level transition, I should at least get an interrupt. But for somehow this just randomly been lost.

I asked for a very slow slope case not because the input signal is varying this slow, it actually should be instant. Just because it is a really weird issue so I am guessing this might be happening for some very exceptional reason.

Or is it possible that the input signal glitches or bouncing may cause 833 GPIO detect fail?

[Einar Thorsrud]

I see. This is most peculiar. In the scenario you describe there is ample time between the pin getting configured and the transition to 0, and everything is slow so it should be good. Some generic thoughts that might be irrelevant but it could be good to rule out:

1. Could there be that for some reasons in som cases your app ends up spending all CPU time in a higher priority interrupt, preventing servicing of the GPIOTE interrupt?
2. Another issue in your firmware that makes it seem like the interrupt does not occur. How have you verified that this is what happens?

rolandash said:

Or is it possible that the input signal glitches or bouncing may cause 833 GPIO detect fail?

If the signal is 0 (defined as below 0.3 x VDD9) for an extremely short period of time then that would be a theoretical possibility, but if not this should worst case give you multiple events instead (if the ripple si so high that there are several transactions up and down).

[rolandash]

As you mentioned above, the GPIOTE is edge triggered. So I am thinking if this case can happen that, for some reason 833 detection missed the edge (for example the HFCLK issue?), so after that even the level did have changed to 0 but the interrupt will not happen?

[Einar Thorsrud]

No, that should not be the case. The behavior is that it is edge triggered, but that does not mean that it has to sample during the transition. Rather, it means that the event/interrupt is generated on transitions(if one sample is 1 and the next is 0 there was a transition), and not a steady level.

PS: I am off for Christmas holiday now so I will not be able to reply back to this thread until next year. If you need assistance next week, then please open a new case and refer to this one.