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

Different IRQ priority levels

Hi,

system info:

  • SDK: v6.0.0.43681
  • S110 V7.0.0
  • nRF51822 Rev.2

I’m using a ~4ms one shot timer (using the timer library) which is being started in the RADIO_NOTIFICATION_IRQHandler(). In the timer_timeout_handler() I’m starting an ADC measurement, now my question: The ADC IRQ priority is configured as sd_nvic_SetPriority(ADC_IRQn, NRF_APP_PRIORITY_HIGH);, could this combination cause a problem/error because the RTC1_IRQn in the app_timer.c is configured with APP_IRQ_PRIORITY_LOW?

  • Hi Omar

    I would not think that any of those interrups could effect one another. When the radio notification handler triggers, it starts an app timer and the radio notification handler execution ends. The RTC1 (used by app timer library) eventually generates an interrupt to execute the timer handler, which is a separate execution thread with independent priority.

    The same applies when starting the ADC sampling from the timer handler. It should not conflict with the ADC interrupt handler as the ADC interrupt handler is a separate execution thread.

    I suspect though that the interrupts can interrupt one another if the radio notification interrupts fire too frequently. That could cause the app timer to trigger ADC sampling before the former ADC sample is ready.

    Are you experiencing strange ADC output, or what is the problem?

  • Hi Stefan,

    actually the ADC values are correct. I'm using a connection interval of 7.5ms and the timer has a timeout of 4ms as mentioned, so the ADC is always sampling between the connection events, so within the remaining 3.5ms. I'm using notifications by the way.

    What we experienced was a non-systematic call of app_error_handler(), so after I reviewed my firmware, I didn't find anything unusual but this IRQ priority. At the moment I'm calling NVIC_SystemReset(); in app_error_handler().

    Thanks for the support

  • Hi Omar

    To figure out what causes the app_error_handler to be called, enable debugging instead of resetting, as described on this thread.

    Want to mention one thing in case you did not notice it. Radio notifications can notify the application both before the start of a BLE radio event and when it finishes. So if you want to sample once per radio event and do it when radio is inactive, it is possible to start it on the radio notification that is triggered when the BLE radio event is finished. How to identify the "radio finished" event is described in the radio notification tutorial. If this method suits your purpose, it adds the benefit of not having to enable the timer.

Related