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.

[Simonr]

Hi

I'm sorry you're being sent in a loop here, but now Hieu is out of office. I haven't had time to get into this case, but I have pinged the devs looking at this internally, and will let you know if they have any updates.

Einar who initially had this ticket will return on Monday July 29th and likely take back this case then. So sorry about all the delays.

Thus far I'm afraid there's no further updates from our side. You say that the full log can't be uploaded. Would it be possible to upload it with Google Drive or similar so we can download it on our end from there? Alternatively you can send it by mail to me, but for the mail address I'll reach out to you in direct messages if that's what you prefer.

And just a shot in the dark from me, how many devices has the beacon connected to when this issue occurs. Could it be that the maximum number of connections is reached, and that's why the advertiser won't start again, since it seems to happen after a connection event if I'm not mistaken.

One option you could try is to add a watchdog timer that will reset the device if no BLE events trig in X amount of time. Use the WDT example for reference here.

Best regards,

Simon

[Einar Thorsrud]

Hi,

I have inerited this case back from Simon. For now I do not have anything to add to what he wrote, other than that if the problem with uploading logs is the file type, then I suggest putting the log in a zip file and uploading that. You can uploade large files here on DevZone as long as the file type is allowed (and .zip is).

Br,

Einar

[hiroiwas]

Hello Einar,

> but I have pinged the devs looking at this internally, and will let you know if they have any updates.

> For now I do not have anything to add to what he wrote,

In this case, we have no option but to reset the device, and since the problem is occurring within the SoftDevice, we would appreciate your immediate response.

It's been two months since the problem first occurred and no progress has been made.

If there is any information you require, please let us know and we will do our best to provide it.

> You can uploade large files here on DevZone as long as the file type is allowed (and .zip is).

I previously uploaded Log of the incident.zip, but when I tried to upload the log this time, I was unable to do so.
So I wondered if there was a limit to the upload size, and inquired about it.

Best regards,

[Einar Thorsrud]

Hi,

There was an issue in some SoftDevice versions that coudl cause also important events to be lost if the applications does not pull/process evetns on time. This was fixed in SoftDevice version v7.3.0 though, so I wonder if you can confirm that that is what is used on the failing devices? (You mentionned v7.2.0 as well, where this issue still existed).

It is regardless important to process SoftDevice events in a timely manner. Do you know more about when this issue occurs? Could it be that the application have not pulled events in a long time due to other activity? And if you use the SoftDvice hanler with app scheduler, could it be that the app scheduler queue is too short, for instance?

[hiroiwas]

Hello Einar,

> This was fixed in SoftDevice version v7.3.0 though

Currently the SoftDevice version that is having the issue is v7.3.0.

> It is regardless important to process SoftDevice events in a timely manner.

The most time-consuming BLE event is the process between receiving NRF_BLE_SCAN_EVT_NOT_FOUND(SCAN_RSP) and calling sd_ble_gap_connect (a maximum of about 100 ms).
Specifically, what should be the upper limit for this event processing time?

> Do you know more about when this issue occurs?

This issues always occurred right after sd_ble_gap_connect in the NRF_BLE_SCAN_EVT_NOT_FOUND event.

> Could it be that the application have not pulled events in a long time due to other activity?

The logs at the time the problem occurred show no evidence of any events other than BLE being active.

In fact, no BLE events (<debug> nrf_sdh_ble: BLE event: xx) have been issued from the SD card since sd_ble_gap_connect at the time of the problem.

> And if you use the SoftDvice hanler with app scheduler,

No, SoftDevice events are set to use interrupts.

#define NRF_SDH_DISPATCH_MODEL 0
// <i> NRF_SDH_DISPATCH_MODEL_INTERRUPT: SoftDevice events are passed to the application from the interrupt context.

FYI, this issues seems to be the same.

Best regards.

[Einar Thorsrud]

Hi,

I see. I understand that this issue is difficult to reproduce, but are you ablet share a project that can reproduce this on a DK (given enough time)?

Regardgin the other thread that is using the nRF Connect SDK which is using a different Bluetooth stack (though the controller / link layer inherits components from the SoftDevice).