using app scheduler does not prevent BLE stack starvation

RE: using app scheduler does not prevent BLE stack starvation

Allen — Tue, 29 May 2018 16:06:07 GMT

It is set to 0.

I did try setting it to 1 and increasing the queue size to see if that fix the problem. It did not and seemed to perform worse than the default configuration.

RE: using app scheduler does not prevent BLE stack starvation

MattyIce — Tue, 29 May 2018 16:01:49 GMT

What is `NRF_SDH_DISPATCH_MODEL` set to in your project? My understanding is that if you've set this to 1 or 2 (and not 0) then you will encounter priority issues with the soft device.

RE: using app scheduler does not prevent BLE stack starvation

Allen — Tue, 29 May 2018 15:24:38 GMT

I thought that BLE events were handled in an interrupt context unless the event scheduling method is changed. Is that not true? If so, why would a scheduled event prevent these from being serviced?

RE: using app scheduler does not prevent BLE stack starvation

Kenneth — Mon, 28 May 2018 07:47:35 GMT

I agree with you, ideally there should be some priority within app scheduler to ensure some operations (for instance handling BLE events) could be prioritized. Unfortunately that is not the case, so your workaround to use a timer to "spread" the time consuming tasks over time is I believe the best workaround.

RE: using app scheduler does not prevent BLE stack starvation

Allen — Thu, 24 May 2018 16:48:42 GMT

The whole premise of this issue report is that we should not be blocking BLE for 10 seconds since we are using the app_sched_event_put() to perform the operation in 128 byte chunks.

We are using a bonded communication scheme so an external sniffer does not work. (we tried that)

RE: using app scheduler does not prevent BLE stack starvation

Kenneth — Thu, 24 May 2018 07:23:48 GMT

Is it possible to get a on air sniffer log do you think? Or possible just dump the BLE evt_id to UART, so we may try to find which event that in specific may be the problem here.

The 0x16 error is local host terminated, do you initialize or receive connection update/phy update/ channel map update on the device?

Also does this happen on a peripheral or a central?

A quick calculation on your description means you may be blocking BLE events for 64kB/128B*20ms=10seconds. This is a long time, but should work, so I would like to understand which event in specific that may be time critical.

RE: using app scheduler does not prevent BLE stack starvation

Allen — Wed, 23 May 2018 18:42:05 GMT

Yes, disconnect reason 0x28. 0x16 is also a BLE error code. The last one is probably due to a software error in our code. I could probably get a log file if you are interested.

RE: using app scheduler does not prevent BLE stack starvation

Kenneth — Wed, 23 May 2018 18:36:09 GMT

Interesting, so you may have several 20ms periods where you are not handling any BLE events in between if I understand you correctly. I will run this by the softdevice team.

You write: "Usually the connection terminates with a 0x28 error code. Then we get 0x16 after that."

I assume that you mean that you get disconnect reason 0x28, but not sure what you mean by 0x16? Is this an error code from a specific softdevice call, or are you getting 2 disconnects?

RE: using app scheduler does not prevent BLE stack starvation

Allen — Wed, 23 May 2018 17:27:39 GMT

Here is what we are doing and how it is implemented.

I am erasing 64KB of eeprom connected to the SPI bus. Each time the erase function is called it erases 128 bytes from the eeprom and then reschedules itself. The eeprom SPI interface is *not* interrupt driven. Each erase operation takes about 20ms.

I also investigated the interrupt priorities. However we are never doing anything in an interrupt context. So, repeatedly scheduling 20ms non-interrupt operations with no idle time will kill BLE. Adding a timer delay fixes the issue.

BTW: as another test I changed the SD scheduler configuration to use the application event queue and increased the allocated queue size to 50. If anything, this seemed worse.

RE: using app scheduler does not prevent BLE stack starvation

Kenneth — Wed, 23 May 2018 16:46:34 GMT

Sorry, I still do not quite understand how this is possible. If you take a look at the interrupt priorities for the softdevice and application here:
http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.sds/dita/softdevices/s130/processor_avail_interrupt_latency/exception_mgmt_sd.html?cp=2_3_1_0_15_1

The only thing I can think of is that you are staying much time in priority 2 and 3, thereby then prevent the softdevice priority 4 from running for several connection intervals. Is that what is happening here?

RE: using app scheduler does not prevent BLE stack starvation

Allen — Wed, 23 May 2018 15:45:53 GMT

The BLE events are not getting handled. Usually the connection terminates with a 0x28 error code. Then we get 0x16 after that.

We were able to work around the problem by setting a timer for 12ms that would then queue the event. Initially we tried 10ms but that still failed after awhile.

RE: using app scheduler does not prevent BLE stack starvation

Kenneth — Wed, 23 May 2018 11:59:27 GMT

Hello, I am under the same impression, can you give an example of what is happening here. Are you saying that the BLE throughput is reduced or that you are not handling BLE events?