This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Pin interrupt triggered without transitioning from HI-to-LOW

I am using an ADC where the SPI MISO pin also acts as a data ready pin when it transitions from Hi-to-Low as detailed in the link below. I am able to configure this and it works as intended when I configure the pin to be high accuracy  NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true).

https://devzone.nordicsemi.com/f/nordic-q-a/25047/are-spi-interrupt-disabled-in-gpiote-handler

 

my configurations:

nrfx_gpiote_in_config_t adc_drdy_pin_config = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
err_code = nrf_drv_gpiote_in_init(SPI_MISO_PIN, &adc_drdy_pin_config, adc_drdy_interrupt_handler);
APP_ERROR_CHECK(err_code);
nrfx_gpiote_in_event_enable(SPI_MISO_PIN, false);

the adc_drdy_interrupt_handler gets triggered as soon as the nrfx_gpiote_in_event_enable(SPI_MISO_PIN, false) function is executed. note that I am not even enabling the interrupt event. how can this be happening?

the pin starts low but the handler should NOT be getting triggered since the pin did NOT transition from high to low. if i run the app with NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true), everything functions as it should. I am trying to lower my power consumption and I am using SDK 15.0.0 and S132. I have been at this problem for days and any help would be greatly appreciated.

  • also, the interrupt handler shows that its the MISO pin that is triggering the event. Note, I do not execute any SPI read/write functions up to this point.

  • Hi,

     

    Are you assigning the same GPIO to be MISO, and GPIOTE_IN channel? That would be a pin conflict if both SPIM and GPIOTE is enabled at the same time.

    Is the pin floating externally? Your current configuration does not enable any pull-resistor, so if there's nothing external to pull the pin to a defined level, the event is very likely to occur.

     

    Kind regards,

    Håkon

  • Hi :

    Thanks for the reply! yes, I am assigning the same pin to both the MISO and ADC interrupt GPIO. This works when using high accuracy and according to the above link, the SPI driver takes over the pin when needed which I can confirm since the it works. I also disable the event in the interrupt handler with 

    nrfx_gpiote_in_event_enable(SPI_MISO_PIN, false);

    prior to executing any SPI transactions.

    moreover, when NOT using high accuracy,  the handler is getting triggered before I even configure my SPI pins. according to this link,

    https://devzone.nordicsemi.com/f/nordic-q-a/39768/port-event-interupt-while-sensed-pin-is-active/156280#156280

    calling nrfx_gpiote_in_event_enable always seem to trigger the PORT event, even when it was already handled before. this does not make any sense. Does the nrfx_gpiote_in_event_enable function suppose to trigger the interrupt handler when the pin is configured for a high-to-low transition? the pin is low when the handler is triggered and never transitioned from high-to-low. I tried using the NRF_GPIO_PIN_PULLUP which does nothing since the ADC is keeping the pin low until it is configured and operating. Are there any configurations I am missing in the sdk_config file to setup the port event? this issue is killing our device power so please any help is greatly appreciated.

    Regards,

  • also, how can I make sure they are on different GPIOTE_IN channels?

  • Hi,

    Wael said:
    calling nrfx_gpiote_in_event_enable always seem to trigger the PORT event, even when it was already handled before. this does not make any sense. Does the nrfx_gpiote_in_event_enable function suppose to trigger the interrupt handler when the pin is configured for a high-to-low transition? the pin is low when the handler is triggered and never transitioned from high-to-low. I tried using the NRF_GPIO_PIN_PULLUP which does nothing since the ADC is keeping the pin low until it is configured and operating. Are there any configurations I am missing in the sdk_config file to setup the port event? this issue is killing our device power so please any help is greatly appreciated.

     When you are reconfiguring, did you try the workaround as posted in the thread you linked to? Ie: clearing the event, then enabling it.

     

    Kind regards,

    Håkon

Related