nrf_drv_gpiote_in_event_enable causes event

Hey,

When I call fn nrf_drv_gpiote_in_event_enable, the event handler is immediately called.  Note that at the beginning of the fn I even read the pin to verify it's high.  I also know it's high because I'm scoping it.   Also, this code does work properly when the line transitions to low.

Is there a way to stop this erroneous event from happening when enabled???

    ret_code_t err_code;

    nrf_gpio_cfg_input(gp_board_config->irq, NRF_GPIO_PIN_PULLUP);

    {
        volatile uint32_t read = nrf_gpio_pin_read(gp_board_config->irq);

        // Setting break point here verifies this line is high.
        read++;
    }

    err_code = nrf_drv_gpiote_init();
    APP_ERROR_CHECK(err_code);

    /**
     * Sam will set the interrupt aka wakeup line low until nrf responds with Ack.
     */

    nrf_drv_gpiote_in_config_t irq_config = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(false);
    err_code = nrf_drv_gpiote_in_init(gp_board_config->irq, &irq_config, m_gpiote_evt_handler);
    APP_ERROR_CHECK(err_code);

    CRITICAL_REGION_ENTER();
    nrf_drv_gpiote_in_event_enable(gp_board_config->irq, true);

    {

        nrf_gpiote_events_t event   = nrfx_gpiote_in_event_addr_get(gp_board_config->irq);

        nrf_gpiote_event_clear(event);

        NVIC_ClearPendingIRQ(GPIOTE_IRQn);
    }

    CRITICAL_REGION_EXIT();

Note I even tried disabling ints, and then clearing the event and the interrupt - no success.

Parents
  • Hi,

    Which GPIO pin are you using? Have you tried other pins?

    Since you have passed "false" to the hi_accu argument of NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(), the pin will use the GPIOTE PORT event and not a dedicated IN event. Have you tried setting this to "true"?

    When you say that the event handler is called immediately, is this your application defined event handler? (m_gpiote_evt_handler) What are the pin and action variables set to?

    The code you have included in your post is not correct to clear events:

    nrf_gpiote_events_t event   = nrfx_gpiote_in_event_addr_get(gp_board_config->irq);
    nrf_gpiote_event_clear(event);

    nrfx_gpiote_in_event_addr_get() will return the address of the event register, while nrf_gpiote_event_clear() expects a nrf_gpiote_events_t enum value.

    Since you have set the hi_accu parameter to false, you can try passing the NRF_GPIOTE_EVENTS_PORT option to nrf_gpiote_event_clear().

    Best regards,
    Jørgen

  • Jorgen,

    Thanks for your reply.

    Thanks for the tip on the param for nrf_gpiote_event_clear, I struggled with that.  Using NRF_GPIOTE_EVENTS_PORT did not fix the problem.

    Setting hi_accu to true does fix this problem.  But this product is powered from coin cells and I believe that causes higher current draw due to use of HFCLK (this solution has a crystal on HFCLK, as the radio is used occasionally)  - so I think setting hi_accu to true is NOT a permanent solution.

    The goal is the get an interrupt when the GPIO line transitions from high to low - should I be using another technique other than nrf_drv_gpiote_in_init?

    
    
Reply
  • Jorgen,

    Thanks for your reply.

    Thanks for the tip on the param for nrf_gpiote_event_clear, I struggled with that.  Using NRF_GPIOTE_EVENTS_PORT did not fix the problem.

    Setting hi_accu to true does fix this problem.  But this product is powered from coin cells and I believe that causes higher current draw due to use of HFCLK (this solution has a crystal on HFCLK, as the radio is used occasionally)  - so I think setting hi_accu to true is NOT a permanent solution.

    The goal is the get an interrupt when the GPIO line transitions from high to low - should I be using another technique other than nrf_drv_gpiote_in_init?

    
    
Children
No Data
Related