Soft Device Freeze NUS, Scan, FreeRtos

[LukeC]

I have an application that is running the following setup as a multi-connection (peripheral and central) setup:

// <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
#ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 3
#endif

// <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links. 
#ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
#define NRF_SDH_BLE_CENTRAL_LINK_COUNT 2
#endif

// <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Maximum number of total concurrent connections using the default configuration. 
#ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
#define NRF_SDH_BLE_TOTAL_LINK_COUNT NRF_SDH_BLE_PERIPHERAL_LINK_COUNT + NRF_SDH_BLE_CENTRAL_LINK_COUNT
#endif

I am having an issue when a peripheral (NUS) is sending and receiving significant amounts of data over BLE I get the Soft Device locked up.

 I am running FreeRtos and can tell my tasks are alive via button presses and RTT commands.

However, when I get this  soft device ble "freeze" I get the following symptoms that seem to indicate the Soft Device is locked up:

1. I see a disconnect on the IOS side and do not get BLE_GAP_EVT_DISCONNECTED on the Nordic side.

2. BLE advertising stops when it was previously running

• Is the Central Scan causing this?
  
  • If I disable scanning I do not get the freeze.
  • If I increase the SCAN_INTEVAL and reduce the SCAN_WINDOW, the freeze takes longer, but still seems to occur after a few minutes of stress testing the NUS ble comms.
    
    These settings also really slow down connections to my peripheral.
    
    

  • #define SCAN_INTERVAL MSEC_TO_UNITS(300, UNIT_0_625_MS)
    #define SCAN_WINDOW MSEC_TO_UNITS(10, UNIT_0_625_MS)
    #define SCAN_TIMEOUT 0x0000 //MSEC_TO_UNITS(10000, UNIT_10_MS) //0x0000 /**< Timout when scanning. 0x0000 disables timeout. */
    
    
    /** @brief Parameters used when scanning. */
    static ble_gap_scan_params_t const m_scan_params = {
        .active = 1,
        .interval = SCAN_INTERVAL, // SCAN_WINDOW * 2,
        .window = SCAN_WINDOW,
        .timeout = SCAN_TIMEOUT,
        .scan_phys = BLE_GAP_PHY_CODED | BLE_GAP_PHY_1MBPS,
        .extended = 1,
        .filter_policy = BLE_GAP_SCAN_FP_ACCEPT_ALL,
    };

    44
• Is there some sort of soft device call back I should be getting that should be reporting a critical error?
  
  
• Perhaps there is a softdevice function I can check to see if I am taxing the soft device too hard or if the radio has been locked up too long?
  
  
• Perhaps there is an issue with the BLE stack size in FreeRtos?  I tied increasing it to 256*5, but that didn't change anything.
  
  
• Perhaps I need to change my scan interval and my advertising interval and other connection intervals to maintain all of these connections?
  
  
• Are there any improvements in SDK 17 that would help with this condition?

I know I am really doing a lot of simultaneous connections while scanning (on by Phy speeds!) and advertising.   Any help in identifying the stack lock up and how to mitigate this with this many connections would be very helpful.  I am guessing I have to slow things down a bit.

IDE: SES

PART: NRF52840

STACK: 16

Soft Device 7.0.1

[WestCoastDaz]

LukeC

What are the task priorities?  The BLE task should be high if not the highest.  Note that in FreeRTOS a high number means a higher priority.

[LukeC]

I have been concerned about that as well, but I think I have the priorities set right.

All of my tasks are either priority 0 or 1 while the SDH task is priority 2.

If I pause when the stack freezes, I see the IDLE task as the one executing, which indicates the BLE task is not blocking. It sure seems like it is the soft device locking up which runs at a higher priority than any of the FreeRtos tasks...

[LukeC]

So, I found another thread that proposed removing the SDH task and using the interrupt dispatch model.

Is there any extra risk from this approach?  It seems to have fixed the issue, I can even push scanning to 20ms window / 10ms interval.

// <i> NRF_SDH_DISPATCH_MODEL_INTERRUPT: SoftDevice events are passed to the application from the interrupt context.
// <i> NRF_SDH_DISPATCH_MODEL_APPSH: SoftDevice events are scheduled using @ref app_scheduler.
// <i> NRF_SDH_DISPATCH_MODEL_POLLING: SoftDevice events are to be fetched manually.
// <0=> NRF_SDH_DISPATCH_MODEL_INTERRUPT 
// <1=> NRF_SDH_DISPATCH_MODEL_APPSH 
// <2=> NRF_SDH_DISPATCH_MODEL_POLLING 

#ifndef NRF_SDH_DISPATCH_MODEL
#define NRF_SDH_DISPATCH_MODEL 0
#endif

[WestCoastDaz]

LukeC

I am currently using FreeRTOS in that fashion and I haven’t had an issue.