How do I size the App Scheduler to take advantage of NAKs from the SoftDevice?

Question

This is a follow-up to my previous post . I'm developing a BLE Peripheral application on the nRF52832 that uses NRF_SDH_DISPATCH_MODEL_APPSH to receive events from the SoftDevice. My application involves using some software-implemented elliptic-curve cryptographic computations in APP_IRQ_PRIORITY_THREAD, which can take up to 1.5 seconds to run. 
 I found that if I send enough Characteristic Writes while the nRF52832 is doing the ECC computations, I can cause one of two effects, based on how I've configured the size of the App Scheduler. If it is 50, app_sched_event_put() in SD_EVT_IRQHandler() returns NRF_ERROR_NO_MEM. If it is 60, then I instead see NAKs from the SoftDevice to the Central on my BT sniffer. 
 My understanding is that this is because if the SoftDevice can buffer more Writes than the App Scheduler, it will overflow the App Scheduler because it can enqueue events from an interrupt context. However, if the App Scheduler is large enough, it will be able to handle all the events from the SoftDevice, and because the ECC computations are preventing another call to nrf_sdh_evts_poll(), the SoftDevice's internal buffers will fill, so it will start to NAK Writes from the Central. 
 I would like to be able to rely on the NAK behavior, so I need non-experimental reasoning for why there is this change in behavior between the App Scheduler sizes of 50 and 60. What is the maximum number of events that the SoftDevice could buffer from BLE because of, say, a malicious Central? 
 I am using s132 v5.1.0.

Einar Thorsrud · Accepted Answer

Elias said: Here's an alternate question: how would I go about verifying that the SoftDevice can only buffer 6 events? 
 I ended up with a delay in the event handler to try to show this, but it turns out that my memory did not serve me well, so I have been giving you outdated and incorrect information. In the older SoftDevices it was the case, but in more recent versions the buffer in the SoftDevice is adjusted based on parameters like event length and MTU size (typically set by NRF_SDH_BLE_GAP_EVENT_LENGTH and NRF_SDH_BLE_GATT_MAX_MTU_SIZE) in sdk_config.h. So you could reduce these to reduce the buffer. 
 If you have some data that you want the peer to know if/when is actually received and processed or not, so that the peer can act on that, then this might be a situation where you would want to use something like indications instead. An indication has acknowledgement on the application layer.

How do I size the App Scheduler to take advantage of NAKs from the SoftDevice?

Top Replies