What is a reason of the definite SoftDevice assertion handler: m_line_num: 811; m_p_file_name: src\ll_lm.s0.c

[hardware-dept]

Hello,

We start using of our BLE devices with more or less permanent connection with our central BLE device, it was needed for Alisa connection.

BLE peripherals are old enough devices with SoftDevice S110 v7.0.0 SDK v6.0.0 on nrf51822AA, they are already in production state (that is why we can not change SoftDevice version to more newer).
Central is like a gateway from WiFi to Blutooth and vise versa. (BLE part is on nrf52832AA, S132 v2.0.0, SDK v11.0.0) 

And we found out some troubles of peripherals (resets, hangings) only after we started usage that configuration with permanent connection.
But really there are a lot of BLE disconnections with subsequent recovery a connection (we saw that with RTT Viewer). Then we deepened into the bug problem, and found out the following bug text inside our peripherals:

m_line_num: 811; m_p_file_name: src\ll_lm.s0.c

That was produced by SoftDevice assertion handler.
It was confirmed a few times on two various types of our peripheral BLE devices. To reproduce this bug we were waiting a lot of time (during a few days). 
Also we supposed, that the bug arises at the moments of connection event time.

Q: What is an exact reason of that bug text, and what are your recommnedations in our situation?

Thank you in advance.

[Kenneth]

I am contact with softdevice team to get their input. 

One question, are you disabling interrupts for any period of time in your code?

[hardware-dept]

Hi,

Yes, there is a very short interruption in one of our two tested projects:
exactly, two operators inside critical section in function that is called from main cycle, it's like
CRITICAL_REGION_ENTER(); a = b; b = 0; CRITICAL_REGION_EXIT();

But another project contains critical region only at advertising initialisation stage (at start of device) one time. I think critical regions is not the cause in our projects because the assertion condition arises in both projects after several hours from starting of devices.

We are looking forward to answer from softdevice team.
And that is urgently.

[Kenneth]

Hi,

It seems to be related to rapid connections and disconnections and consecutive start/stop advertising events. This trigger a race condition between BLE connection/disconnect event, LL procedures and (re-)start of advertisement. Can you for instance try to wait  along period of time (e.g. 6 seconds) from disconnect event until you start advertising again?

In worst case you may need to consider disable and re-enable the SoftDevice after each disconnect to avoid the assert.

Kenneth

[hardware-dept]

Hi,

Firstly, thanks for your advice. My intuition says to me that this is a right way.

We started a test with delayed advertising after disconnected event (in two types of our devices), as you adviced us. We checked advertising data in Master Control Panel, and we saw the 6s pause in advertising data after disconnected event (we output counters of connected/disconnected events into advertising data and RTC1 counter too). It works as you suggested. And we will wait some result during a few days.

Only one question. Why 6 seconds? It maybe long enough time for our clients to restore a connection for device control. What is a reason for this time value, can we reduce this delay time to 0.5s for example?

Best regards

[Kenneth]

Hi,

I believe the reasoning behind the long delay are related to the supervisor timeout of the previous link.

Kenneth