Crash due to softdevice assert (id:0x1 pc:0x3FDA info:0x0)

[Eddie]

Hi. We are using the nRF52 sdk v15.2 with S132 v6.1.0 on a nRF52832. Sometimes, when connecting, we get a crash with

identifier 0x1

program counter 0x3FDA

fault information 0x0

In the log when a connection succeeds, we see:

00> [00:14:03.335,221] <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 27 bytes.
00> [00:14:03.335,237] <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
00> [00:14:03.395,204] <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
00> [00:14:03.395,220] <debug> nrf_ble_gatt: max_rx_octets: 27
00> [00:14:03.395,235] <debug> nrf_ble_gatt: max_tx_octets: 27
00> [00:14:03.395,250] <debug> nrf_ble_gatt: max_rx_time: 328
00> [00:14:03.395,265] <debug> nrf_ble_gatt: max_tx_time: 2120

When it fails, we see this:

As you can probably see, our device supports 2 connections at the same time. I suspect it fails when 2 connections are being set up at the same time. Or a connection is setup while a disconnect happens? Any idea what is causing this and how we can avoid it?

[Susheel Nuguru]

It seems to me based on your PC value that the assert is happening inside the scanner where the controller concluded that the advertising event has concluded on wrong conditions. Is it possible for me to reproduce this on my end? Are you using Advertising Extensions?

[Eddie]

We are not using advertising extensions. We are advertising very fast (20ms) and have changing advertising data and scan response data at this frequency. We are also scanning (passive scanning, no filter). And we accept 2 ble connections  (so advertising in BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED with 0 or 1 connection, advertising BLE_GAP_ADV_TYPE_NONCONNECTABLE_SCANNABLE_UNDIRECTED with 2 ble connections).

[Susheel Nuguru]

It looks like you had this similar issue one year ago in the support case 249159 requested by [email protected].

In that issue my colleague wrote that

I can now confirm we have seen some issues like this, where there is a potential race condition in the SoftDevice. Especially if you do non-connectable advertising after connectable advertising. Is that what you do?

A proposed workaround is to not advertise right after getting a connection, but rather wait a few 10s of ms before restarting the advertising. Does this make the asserts go away for your device?

With additional information about the nature of advertising/scanning/connections we may be able to tell more about the issue and confirm if the potential issues we have identified are the same as you are experiencing. Information such as type of advertising (connectable / non-connectable), scanning, connection parameters, do you often change the advertising data, etc.

Have you removed the scan timeout timers that you have implemented as a workaround for this?

[Eddie]

I believe we have not changed anything, except the way scanning is started/stopped. We set the timeout to 0 and use our own timer to start and stop scanning. Looks like the same problem is back. So it's the advertising that needs to be changed?

We are advertising non-connectable after connectable (and the reverse) when needed. Waiting a few 10s of ms before starting advertising after a connection seems like a dirty fix. Are we sure this is going to solve the problem? Would it not be better to solve the race condition in the softdevice?

[Eddie]

Also, wondering why we only have to wait to start advertising after a connection. Why isn't this needed on a disconnect (and switch from non-connectable to connectable)?