APP_BLE_OBSERVER_PRIO and NRFX_GPIOTE_CONFIG_IRQ_PRIORITY

[buja]

SDK- nRF5_SDK_17.0.2_d674dde

SD - s112_nrf52_7.2.0

Hi Team,

I have configured a gpioTE and the Interrupt priority is set 6. (#define NRFX_GPIOTE_CONFIG_IRQ_PRIORITY 6 in sdk_config.h ).

I have a handler for BLE events. NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);

APP_BLE_OBSERVER_PRIO is set as 3.

from gpioTE handler I am sending a beacon and waiting for the response. But ble_evt_handler() is not getting called from gpioTE handler ?

I expect ble_evt_handler() to preempt gpioTE handler because the priority of ble_evt_handler() is 3(APP_BLE_OBSERVER_PRIO) and  gpioTE  is 6. Can you please explain me why the premeption is not happening ?

Here is the psuedcode

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)  //priority3 as per my understanding
{
ret_code_t err_code = NRF_SUCCESS;

switch (p_ble_evt->header.evt_id)
{
case BLE_GAP_EVT_ADV_SET_TERMINATED:
adv_in_progress = 0;
NRF_LOG_INFO("Advertising set terminated.");
break;
default:
// No implementation needed.
break;
}
}

gpioTE_handler()  //priority 6

{

adv_in_progress = 1;

send_beacon();

while(adv_in_progress){ //not getting cleared

idle_state_handler();

}

}

 

[Vidar Berg]

Hi,

The observers are actually invoked in the same SD_EVT_IRQn interrupt context regardless of the observer priority setting. The observer priority is controlling what order the observer callbacks are stored in flash, and thus the order of which they are called when you have multiple observers (Assigning priorities).

I would suggest that you try to move the wait function to your main loop to reduce the time spent inside the GPIOTE ISR. E.g. by setting a volatile status flag inside the interrupt that is polled by your main loop.

Best regards,

Vidar

[buja]

Hi Vidar,

Thank you for your prompt reply. There is some limitation in implementing it in main loop due to critical regions.

sd_nvic_SetPriority(SD_EVT_IRQn, 5); --> I tried this and it is working but is it safe to increase the priority from 6 to 5. Will it affect any other operations ?

[Vidar Berg]

Hi,

To reduce the risk for potential race conditions in other SDK modules, it would probably better if you reduced the priority of your GPIOTE interrupt to '7' and keep the original priority for the SD_EVT_IRQn . 

That said, it's not clear to me how the critical regions are preventing the wait loop to be placed in your main loop. Ideally you should try to avoid wait functions inside interrupts.

[buja]

Hi Vidar,

Thank you for your reply.

Vidar Berg said:

To reduce the risk for potential race conditions in other SDK modules, it would probably better if you reduced the priority of your GPIOTE interrupt to '7' and keep the original priority for the SD_EVT_IRQn

In the above said case I will be calling send_beacon (sd_ble_gap_adv_start) function from gpioTE handler  and I hope an SVC call from gpioTE handler (priority 7) will not cause any issue.

Vidar Berg said:

That said, it's not clear to me how the critical regions are preventing the wait loop to be placed in your main loop. Ideally you should try to avoid wait functions inside interrupts.

Mine is not a time critical application. And there are no much Interrupts. Since this is straight forward I implemented it in this way. Anyway I will try to move it to main to make it ideal

[Vidar Berg]

Hi,

buja said:

In the above said case I will be calling send_beacon (sd_ble_gap_adv_start) function from gpioTE handler  and I hope an SVC call from gpioTE handler (priority 7) will not cause any issue.

 It's not a problem to make SVC calls from interrupt priority 7, so this should be fine.

buja said:

Mine is not a time critical application. And there are no much Interrupts. Since this is straight forward I implemented it in this way. Anyway I will try to move it to main to make it ideal

 I understand the motivation for doing it like this, and it is probably going to work OK. Other higher priority interrupts will get processed still.

[buja]

Thank you Vidar :) Have a great day

[Vidar Berg]

No problem