Softdevice behavior during long interrupt using scheduler

[Rafig]

Hello, 

We have an app_timer that runs periodically for the application, and we are also using BLE peripheral code. Once the application timer expires, the event handler code takes around 200ms to execute (read sensor data, algorithm processing and etc.). Assuming that we are using scheduler both for the timer and the softdevice, what will happen if softdevice related interrupts get fired during this period? 

As I understand, the softdevice code that had to be executed inside the interrupts will be postponed into the next scheduler queue element. In other words, SD related activities will be delayed by 200ms. 

Below is graphical illustration for better understanding:

What will be the consequences of it? 

Is it safe to use it in this way?

What is maximum allowed time that we can spend inside scheduler element so that softdevice can work properly? 

[Turbo J]

Setup interrupt riorities properly, i.e. assign the lowest priority (highest number) to the RTC interrupt.

The timing sensitve softdevice interrupts run at high priority and will preemt your 200ms code path.

[Rafig]

Thank you for the reply. How can it preempt 200ms code if it is inside the scheduler?

[Kenneth]

Please take a look at:
https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/processor_avail_interrupt_latency/exception_mgmt_sd.html

And in specific if you are in a connection as a peripheral device:
https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/ble_processor_avail_interrupt_latency/ble_peripheral_connection_performance.html

Best regards,
Kenneth

[Rafig]

Hi Kenneth, thank you for sharing the links, there are very informative. But these links don't mention app_scheduler. 

My question is in the context of using app_scheduler. Both application and softdevice can generate interrupts, and they both use app_scheduler in our case. Application interrupt code takes 200ms to execute. Since we use app_scheduler, the code that takes 200ms is put into the main context(into the scheduler queue). Let's say the scheduler starts executing this queue element, and during this period softdevice interrupt is fired. Softdevice won't be able to execute its code in the interrupt context, and scheduler will put softdevice activities into the next queue element. In other words, softdevice activity is delayed by 200ms because scheduler will postpone it. I hope I was able to explain my concern. Please correct me if misunderstand the concepts.

That's why I asked these questions:

"What will be the consequences of it? 

Is it safe to use it in this way?

What is maximum allowed time that we can spend inside scheduler element so that softdevice can work properly?"

[Kenneth]

You are only delaying the processing of BLE events from the softdevice that the application should handle in one way or the other. The softdevice will still ensure that all real-time requirements are met (the link is maintained). If the application processing is slow (e.g. due to 200ms delay caused by other processing), then this will not have a direct impact on the link, other than increased latency of data and reduced throughput. You would need to stall ble event handling with several seconds before you potentially could get into issues (even those I believe are in the tens of seconds timeout).

Kenneth