Beacon output suddenly stops

[hiroiwas]

Hello.

In the BLE software being developed, the device uses nRF52840, s140 v7.2.0 or v7.3.0, and I am building a system that periodically sends a beacon (ADV_NONCONN_IND) in the peripheral role at the same time as scanning in the central role.

In the software currently under development, after setting a beacon (ADV_NONCONN_IND) and executing ble_advertising_start, the advertisements at the set interval suddenly stops after a while.

The time it takes for the problem to occur varies, ranging from a few hours to several tens of hours, and other functions appear to be working fine even after the problem occurs.

The operation of this device is to continuously perform a sequence of transmitting beacons, connecting in a central role based on advertisements from external devices that capture the beacons, and then disconnecting after communication.
For this reason, the central role frequently start and stop scanning, connects and disconnects, but the peripheral role's beacon output has never stopped since the start advertising.

I believe that the output of ADV_NONCONN_IND started with ble_advertising_start will not stop unless sd_ble_gap_adv_stop is executed, but is it possible that external factors such as SCAN or connection of the central role can stop advertising of peripheral roles?

Also, as a failsafe, we are considering implementing code that monitors the advertisement output and restarts it when the advertisement stops, but is there a way to detect that the ADV_NONCONN_IND has been output to RADIO?
I looked into Radio Notification, but since the event callback can only receive the radio_active state, I determined that it is not possible to capture only the advertisement output in a multi-role operating environment.

Please give me some advice.

best regard.

[hiroiwas]

Hello Einar,

A private ticket has been issued.
Thank you for your continued support until the issue is resolved.

Best regards.

[Einar Thorsrud]

Hi,

That sounds good. let us continue the discussion in the private ticket for now.

[hiroiwas]

Hello,

A tentative conclusion has been reached on the private ticket side, so I will post it here.

The issue occurred in the following scenario:

1. An error occurred in the initiator when connecting.
☞ Example: The peripheral address changed after sd_ble_gap_connect(), the peripheral was shutdown, deterioration of radio wave conditions, etc.

2. In SoftDevice, the initiator where the error occurred will not be able to accept the next ADV_IND.

3. Because the scan timeout is set to 0 (no timeout), the initiator error state continues.

4. Being unable to escape from the initiator causes the scheduler (time slot) inside the SoftDevice to lock, causing the SD to become unresponsive from the app's perspective.
☞ The SD becomes unresponsive, but the app continues to run.

5. If the time slot stops working, the next beacon cannot be sent.
☞ This was the first issue that encounted.

6. Since the RADIO time slot processing will no longer work, subsequent Radio notifications will also stop.
☞ A fail-safe measure that resets itself by monitoring the time when no response is received from the radio notification

This issue occurs because the peripheral address update in 1 causes 3, and also because 2 causes 3.

The solution is to set the ble_gap_scan_params_t::timeout (given by sd_ble_gap_connect) on the initiator where the malfunction occurs to a significant value other than 0, and to resume scanning when BLE_GAP_EVT_TIMEOUT of the BLE_GAP_TIMEOUT_SRC_CONN event occurs.

Regarding the SoftDevice fix in 2., we have received the answer that, given the state of the live cycle, unfortunately, it is highly unlikely that this issue will be fixed  (see the nRF Connect SDK and nRF5 SDK statement given in 2021).

That's all.