GPIOTE freezes on pin value change

[Dan]

I currently have a problem with the gpiote setup. I'm using it to detect an interrupt from mma8652 accelerometer.

here is an annotated version with the key portions of the code.

pin_event_handler()
{
    NRF_LOG_INFO("\r\n PIN 26 triggered \r\n");
    NRF_LOG_FLUSH();
}

static void accel_intrpt_pin_config()
{
    nrf_drv_gpiote_in_config_t config = GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
    config.pull = NRF_GPIO_PIN_PULLUP;
    err_code = nrf_drv_gpiote_in_init(26, &config, pin_event_handler);
    APP_ERROR_CHECK(err_code);
    nrf_drv_gpiote_in_event_enable(26, false);
}

main()
{
    // basic inits
    ...
    while (1)
    {
        ...
        // wait for interrupt from accelerometer to trigger pin 26 -- I never get past this
        while(nrf_drv_gpiote_in_is_set(26) == 1)
        {
            nrf_delay_ms(1000); // check every second just to be sure we didn't freeze early
            NRF_LOG_INFO("\r\n PIN 26 value: %u \r\n",nrf_drv_gpiote_in_is_set(26));
            NRF_LOG_FLUSH();
        }
    }
}

this is the ending uart output after which nothing happens

APP:INFO:
PIN 26 value: 1
APP:INFO:
PIN 26 value: 1
APP:INFO:
PIN 26 value: 0

so I see the pin changes but I never get to my trigger comment in the event handler. I'm sure I'm missing something but I haven't really been able to figure out what. When it reached the point in the code where a change was detected, the whole things stops and when I try to flash the code again to restart it, it freezes at the accelerometer register setup and I have to disconnect to remove the power to the MCU and re-connect to get it going again.

I was using the pin_change_int example to structure this. This wasn't a very complicated thing so I figured that was all I needed. then I was looking on other solved question and I saw all these other things on interrupt and priorities. Is that necessary?

[Jørgen Holmefjord]

Hi,

You need to set the int_enable parameter in nrf_drv_gpiote_in_event_enable() to true to enable the interrupt. If you look in the implementation of the function, you will see that interrupt and handler is only set if this parameter is true.

Best regards,

Jørgen

[Dan]

This appears to have worked as I can now trigger the statement in pin_event_handler. As a follow-up question, is there something that stops the function form going on after hitting the interrupt? It seems to just stop doing anything in the outermost while loop in function main? I've seen other question that reference NRF_GPIOTE->EVENT_PORT = 0 NRF_GPIOTE->EVENTS_IN[0] but I don't quite understand how these work or if they are related at all to make the code continue.

I assume this should be fairly common action to code where a sensor sends an interrupt and I want to take take note of that and call a read on the data. I haven't seen any examples but is there anything I can reference for this?

[Jørgen Holmefjord]

I tested your code and it seems to contine as expected for me. Are you doing anything else in your code? Is the interrupt pin from the accelerometer cleared again after being set? You should not have to do anything with the registers when using the driver, it should handle this for you.

[Dan]

The MMA8652FC technical data sheet says that reading the F_STATUS register should clear the FIFO interrupt flag that I send and I do that. There is another function call in main to read out the accelerometer data. I based that code off the temp_sensor example. Here is a link to main.c

[Jørgen Holmefjord]

I tried your code again, and it still seems to continue after getting interrupt (commented out the TWI transfer functions, as I don't have that accelerometer available). I suppose you have removed the if(0) statement to get the code further down in main() to run? Have you tried debugging, to see if any functions return error codes, or that the application is continuing as expected?

[Dan]

I'm using eclipse and am having trouble getting debug working. While I try to get that running could I ask what is your definition of continuing is for this code? My definition is that I expect to see data_handler() being called repeatedly and seeing my TWI values in uart. The interrupt period is longer than the print call and there is plenty of time to see it written to the uart between interrupts so I don't expect that to be the issue. Am I wrong somewhere?