S130 Softdevice hard fault info request

RE: S130 Softdevice hard fault info request

user8164 — Tue, 10 May 2022 10:56:21 GMT

Hi,

To elaborate: I do not suspect an error in your code, but rather a known bug in the SoftDevice. It may however be possible to mitigate the bug through changes in the application. It may be worth trying to send less data per connection interval, and/or to increase the connection interval.

If what you see is the issue that we think it may be, then you will see (very seldom, but sometimes) that if you send more data than what fits for one connection event, there might be a glitch in the scheduling of the following connection event that triggers an assert. It will happen randomly at very low probability, similar to what you experience. (In your case, two asserts for 24 connections running for 5 days sending data every 10 seconds. If my calculations are correct that corresponds to around 2 ppm.) Since this is a timing related issue, any changes in code that affect timing in the sending of data might change the characteristics of the issue.

Regards,
Terje

RE: S130 Softdevice hard fault info request

user8164 — Mon, 09 May 2022 13:13:48 GMT

Hi,

The PC gives a strong hint there is something wrong with the SoftDevice scheduling. Usually this is due to timeslot bugs in the application, but in your case since you are not using timeslots this is less likely to be the case.

There is one known issue affecting the given SoftDevice, which may be the issue that you are seeing now. It has been very difficult to reproduce, and was not fixed for the S130 (the latest S130 release, v2.0.1, was released prior to the fix of the given issue.) What connection parameters do you use, and how much data is transferred each burst?

Regards,
Terje

RE: S130 Softdevice hard fault info request

user114575 — Mon, 09 May 2022 12:58:21 GMT

Were both the failing devices centrals? And the peripherals of those pairs has been working flawlessly?

Both faults were reported on centrals, we do not appear to have faults on any of the peripherals.

No, we will try the other troubleshooting steps next.

However, we wanted to know first if the program counter would give any hints on what is happening in the softdevice:

Could this error be due to having 24 pairs of devices in one room?

Is the cause likely due to a bug in our application?

RE: S130 Softdevice hard fault info request

user8164 — Mon, 09 May 2022 12:54:11 GMT

Hi,

Thanks for the additional info.

Just to confirm: Were both the failing devices centrals? And the peripherals of those pairs has been working flawlessly?

Have you tried increasing the error rate, e.g. by reducing the time between bursts, increasing the length of the bursts, increasing network traffic (adding more device pairs)? You may of course trigger other errors then, but if you get asserts at the same PC location it would likely be the same issue. Easier reproduction would mean easier to investigate.

Have you tried to reproduce with units that do have debug port access, in order to get more info from the device (such as logs, do a proper debug session, etc.)?

Since the error rate is relatively low, I assume you do not have any sniffer trace from when the error happens?

Regards,
Terje

RE: S130 Softdevice hard fault info request

user114575 — Mon, 09 May 2022 12:13:17 GMT

Is the application using the SoftDevice timeslot library?
No. There are not any calls to sd_radio_request() or sd_radio_session_open()

What BLE roles are you using?

This device is configured as a central. During this test, the central device scans and reconnects to a single, previously paired/bonded custom device. The central periodically writes data to the peripheral, and periodically receives notifications.

This device is writing/getting notifications of the same messages over a 5 day period. Writes and notifications should only happen in short bursts every 10 seconds, unless we have a bug in the application.

We have 24 device pairs (24 central, 24 peripheral) in the same small room.

What is the application doing immediately prior to the fault / does it appear in one specific situation?

This is what we are trying to determine.

How often does it happen, and is it happening repeatedly for some devices and not for others, or is it an even spread?

These faults appear random, we had it happen on 2 devices out of 24 during a 5 day test.

RE: S130 Softdevice hard fault info request

user8164 — Mon, 09 May 2022 11:11:37 GMT

Hi,

I can confirm it is a SoftDevice assert. It may be related to event scheduling in the SoftDevice, or it may be a timing issue.

Is the application using the SoftDevice timeslot library?
What BLE roles are you using?
What is the application doing immediately prior to the fault / does it appear in one specific situation?
How often does it happen, and is it happening repeatedly for some devices and not for others, or is it an even spread?

Regards,
Terje