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

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
  • Hi,

    If you are using revision Rev 1 (QFAA-B00, QFAB-B00, CIAA-B00, CHAA-B00) or revision Engineering C (QFAA-BB0, CHAA-BA0, CIAA-BA0) chips then you do not need to implement PAN73 workaround. It only applies to older Engineering B (QFAA-BA0, CHAA-AA0) and Engineering A (QFAA-AA0, QFAA-AC0, CGAA-AA0) revisions.

    The behavior with peripheral interrupt along with softdevice activity has been discussed extensively in this forum. In short, the softdevice has highest priority over everything and depending on your BLE activity, softdevice will use CPU time that delays your peripheral interrupt being services until softdevice releases the CPU. You can use APP_IRQ_PRIORITY_HIGH for your interrupt so that this is the next thing serviced after softdevice code. This will improve the frequency of peripheral interrupt servicing but still wont be able to catch up high frequency interrupt.

  • Sorry, i got little confused now. where are you checking for the flag being set? i mean is it inside another ISR? If your GPIOTE ISR is at higher priority than the one checking for flag, then interrupt occuring while in the ISR should be no problem, because then the context that checks for the flag will not get the chance to run at all. Maybe i did not understand correctly the overall architecture of what you are achieving to do. But could you please clarify priorities of GPIOTE ISR and the context where you are checking for the flag

Reply
  • Sorry, i got little confused now. where are you checking for the flag being set? i mean is it inside another ISR? If your GPIOTE ISR is at higher priority than the one checking for flag, then interrupt occuring while in the ISR should be no problem, because then the context that checks for the flag will not get the chance to run at all. Maybe i did not understand correctly the overall architecture of what you are achieving to do. But could you please clarify priorities of GPIOTE ISR and the context where you are checking for the flag

Children
No Data
Related