• State Verified Answer
  • Replies 7 replies
  • Subscribers 72 subscribers
  • Views 4094 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 115657
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

GPIOTE interrupt not being serviced

bvuong87

Hi All,

I'm having trouble running one of my I2C sensors connected to the nrf52 when running at a 200hz sampling rate.

Interestingly enough, the same sensor seems to work just fine when running at 20Hz, so I'm thinking the nrf52 can't keep up with the sensor's interrupt firing every 5ms, while also handling all of the softdevice's timing requirements.

If you look at the attached logic analyzer captures, the top two lines are I2C SDA/SCL connected to the problematic sensor, the third line is the interrupt, and the 4th is the I2C line of the second I2C bus, you'll see that after the 8th interrupt, another interrupt is triggered around 0.6 seconds, but there's no further I2C activity for that sensor.

I'm using SDK11, NRF52 PC10040, S132 V2.0.0, with the scheduler and started the project using the ble_app_template.

Any thoughts or ideas on how I can ensure this GPIOTE interrupt gets serviced? Currently have the GPIOTE priority set low, and am implementing PAN #73

image description

Parents
  • 0

    Hi @aryan,

    Thanks for working through this with me. I think I've figured out what the issue was... In my GPIOTE irq handler, there is a flag set that tells the scheduled function what sort of processing is needed.. i.e:

    void gpiote_event_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    if (pin == GET_GPIO_PIN(24) && action == NRF_GPIOTE_POLARITY_LOTOHI)
    {
        flag = 1;
        app_sched_event_put(NULL, 0, interrupt_event_func);
       
    }
}

    and the interrupt event func:

    if(flag){ do some processing here; flag = 0;}

    I think what was likely happening is another GPIOTE event was occurring before the interrupt finished processing, so the second event's flag was also cleared and never serviced

Reply
  • 0

    Hi @aryan,

    Thanks for working through this with me. I think I've figured out what the issue was... In my GPIOTE irq handler, there is a flag set that tells the scheduled function what sort of processing is needed.. i.e:

    void gpiote_event_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    if (pin == GET_GPIO_PIN(24) && action == NRF_GPIOTE_POLARITY_LOTOHI)
    {
        flag = 1;
        app_sched_event_put(NULL, 0, interrupt_event_func);
       
    }
}

    and the interrupt event func:

    if(flag){ do some processing here; flag = 0;}

    I think what was likely happening is another GPIOTE event was occurring before the interrupt finished processing, so the second event's flag was also cleared and never serviced

Children
Related
Terms of service