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.

[Einar Thorsrud]

Hi,

Advertising should not just stop by itself. Could it be that a connection was established but in some special cases you do not re-start advertising, for instance? Do you have logging on the device that can shead some information on this?

As for a workaround, you are right about radio notifications. That will only tell you when the radio is active, but not for what. I would of course suggest to find the root cause and fix that, but as a workaround perhaps you could regularily stop and re-start advertising?

[hiroiwas]

Hello,  Einar.

Sorry for the slight delay in responding due to low reproducibility and another task.

Subsequent investigation revealed that when this issue occurs, the signal does not reach Radio Notification, so not only advertising but also RADIO stops.

Attached are excerpt logs, a HEX dump, and a RAM dump from when the problem occurred.
The heap is initialized with a 1KB incrementing fill pattern, and the stack is initialized with 0xCC by INITIALIZE_STACK.

Log of the incident.zip

SD is s140 v7.3.0, the SDK is 17.1.0_ddde560, and the build environment is SES V5.44.

Best regards.

[Einar Thorsrud]

Hi,

I see. Have you confirmed that there is no radio activity?

Can you check if you always handle SoftDevice asserts in particular and also all SoftDevice events? I ask because critical events should never be missed, so it would be interesting to check if it is possiblet that you loose some events in your application in special cases.

[hiroiwas]

Hello,  Einar.

I confirmed that there is no radio activity by checking that the radio notification event callback is not received for a certain period of time (30sec).

I believe that asserts that occur in SoftDevices can be trapped with interrupts such as app_error_handler or HardFault, just like in the SDK. Is that correct?

The main loop continues to run after the Radio Notification has stopped, and still responds on the UART, so it doesn't appear to be asserted.

What should I monitor to determine why Radio Notification has stopped?

How can I tell if the SoftDevice is working properly?

Can you get an idea of ​​the operating status of the SoftDevice from the RAM dump I sent?

To be honest, I'm at a loss as to what to do, so I'd appreciate it if you could tell me how to identify the cause.

Best regards.

[Einar Thorsrud]

Hi,

hiroiwas said:

I believe that asserts that occur in SoftDevices can be trapped with interrupts such as app_error_handler or HardFault, just like in the SDK. Is that correct?

Yes, that is correct. If you are using the default error handler from the SDK, this would also detect SoftDevice asserts (and reset for release builds).

hiroiwas said:

The main loop continues to run after the Radio Notification has stopped, and still responds on the UART, so it doesn't appear to be asserted.

I see.

hiroiwas said:

What should I monitor to determine why Radio Notification has stopped?

To monitor, perhaps you could use an app_timer instance and reset it every time you get a radio notification? If it does not come in time, the app_timer would time out and the timeout handler run, so that you can handle it.

hiroiwas said:

How can I tell if the SoftDevice is working properly?

Generally, the SoftDevice shoud not behave like this. You can moitor things like I sugested, and reset if you detect an issue (you could also use a watchdog instead of a n app timer, and feed the watchdog every time you get a radio notification. And if not, the watchdog would reset).

hiroiwas said:

Can you get an idea of ​​the operating status of the SoftDevice from the RAM dump I sent?

No, unfortuantely not.

hiroiwas said:

To be honest, I'm at a loss as to what to do, so I'd appreciate it if you could tell me how to identify the cause.

This is not an expected issue. To be honest, the SoftDevice is very well tested I do not recall seeing such an issue before. I would be interested in a verification that your application does not stop advertising, or alternatively, if there could be an issue with advertising not being restarted after a timeout or a connection (attempt). Could that be the case? Have you done anything to verify this?

[hiroiwas]

Hello,  Einar.

> To monitor, perhaps you could use an app_timer instance and reset it every time you get a radio notification?

I have already done that, and the log I attached last time shows that no events occurred in radio notification for 30 seconds.

> if there could be an issue with advertising not being restarted after a timeout or a connection (attempt). Could that be the case?

There are places where advertising is stopped for switching, but when I check the log, it appears that it is not passing through there.

Just to be sure, I will set the advertising output of the beacon (ADV_NONCONN_IND) and then check whether the issue occurs with software that does not stop it thereafter.

The SoftDevice is designed to stop scanning on connection, but resume scanning on disconnection.

Is there anything else I can do besides monitoring the radio notification to get a clue as to what might be going on?

Best regards.

[Einar Thorsrud]

hiroiwas said:

I have already done that, and the log I attached last time shows that no events occurred in radio notification for 30 seconds.

I see. Then that could work as a recovery mechanism: if you have not had an radio activity for x amount of time, reset to recover. But this will not address the root cause.

hiroiwas said:

Just to be sure, I will set the advertising output of the beacon (ADV_NONCONN_IND) and then check whether the issue occurs with software that does not stop it thereafter.

Sond good. Becase advertising really should not stop by itself (unless there is a timeout, and if so you get an event). And I have not found any other reports of such an issue. So I thin it is hightly likely that the application disables or does not restart advertising when it should.

hiroiwas said:

Is there anything else I can do besides monitoring the radio notification to get a clue as to what might be going on?

I would add extensive loggin everywhere you stop or start advertising, and also log all BLE events (you oculd just log the event ID). Then you could go back in the log when advertising unexpectedly stopped and check if there are any events you did not process or if you did stop (or not start) advertising undexpectedly.