• State Not Answered
  • Replies 7 replies
  • Subscribers 86 subscribers
  • Views 1295 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 274794
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents
  • 0

    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?

  • 0 in reply to Susheel Nuguru

    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).

  • 0 in reply to Eddie

    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?

  • 0 in reply to Susheel Nuguru

    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?

  • 0 in reply to 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)?

Reply Children
  • 0 in reply to Eddie

    My colleague who worked with you with the previous issue is on summer holidays and will be back on Monday. I need to understand more on the indepth technical behavior of this bug from him. We need to wait until he is back.  There are not much details that are recorded that i can see to get more indepth insights on this. Sorry to make you wait and Thank you for understanding.

  • 0 in reply to Eddie

    Hi,

    Eddie said:
    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)?

     it seems that there could be a race condition in the GAP module where it might get to a point in time where it thinks it is running a non connectible advertising while getting a connection.  if you wait few 10's ms before you start the non connectable advertising, it should work as the GAP should be in a settled state by then.

Related
Terms of service