Advertising crash when central and peripheral run simultaneously on the same device

[sascha]

Hi everyone,

we are using nRF52832 with SDK 15.0.0.

Our device uses one central and one peripheral simultaneously that are running independently. Recently, I've faced a stack crash in the next scenario:

1) The central is scanning and the peripheral is advertising.
2) BLE_GAP_EVT_ADV_REPORT event happens (scan has succeeded).
3) The central calls sd_ble_gap_connect() to connect to peer and the function returns NRF_SUCCESS.
4) Peripheral advertisement set is terminated (BLE_GAP_EVT_ADV_SET_TERMINATED).
5) The peripheral gets into adv_event_handler() with the event set to BLE_ADV_EVT_IDLE.
6) From BLE_ADV_EVT_IDLE the peripheral calls ble_advertising_start() to restart advertising after timeout.
7) ble_advertising_start() fails with the error NRF_ERROR_INVALID_STATE.
8) Just after that the central connects successfully and BLE_GAP_EVT_CONNECTED event happens.
9) All the following calls of ble_advertising_start() fail with the same error NRF_ERROR_INVALID_STATE, so it's not possible to restart advertising anymore without microcontroller restart.

The advertising module seems to crash if advertising is restarted between sd_ble_gap_connect() call and BLE_GAP_EVT_CONNECTED event. It happens not always, but it's easy to catch this crash if the adverting timeout is short enough. Sometimes when ble_advertising_start() crashes, also BLE_GAP_EVT_CONNECTED gets lost even though the central connects successfully to its peer.

Currently, we've found workaround to disable advertising with sd_ble_gap_adv_stop() right before the central tries to connect and than re-enable peripheral advertising from BLE_GAP_EVT_CONNECTED event handler. But it makes me thinking that the central and the peripheral may share some resources of the BLE stack and it may cause collisions if they run at the same time.

So, my question is if there are any procedures from the central and the peripheral that are mutually exclusive and can lead to the BLE stack crash when they run in the same time? Is it possible to make the central and the peripheral co-existing in the same device independently without any interference?

[Jared]

Hi,

Have you adjusted the link count in the sdk config file? Could you share your entire config file?

regards

Jared 

[sascha]

Hi Jared,

here is my configuration for the link count:

// <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
#ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1
#endif

// <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links. 
#ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
#define NRF_SDH_BLE_CENTRAL_LINK_COUNT 1
#endif

// <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Total link count. 
// <i> Maximum number of total concurrent connections using the default configuration.

#ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
#define NRF_SDH_BLE_TOTAL_LINK_COUNT 2
#endif

The entire configuration file:

3858.sdk_config.h

[sascha]

Please, find the minimal test project attached. The advertising timeout BLE_APP_ADV_FAST_TIMEOUT is set small here (300ms) that makes the issue easy to reproduce. To test the project an another peripheral that accepts connections is needed. It's MAC address is set in ble_app_peer_mac_addr structure. If advertising start chashes in time of central connection, then I additionally try to restart it after disconnect and it also crashes.

adv_test.zip

When the crash of advertising happens the Debug Terminal log looks like this:

<info> app: adv started
<info> app: adv timeout
<info> app: central connected
<info> app: adv start error = 8
<info> app: adv timeout
<info> app: on connect
<info> app: on disconnect
<info> app: adv restart error = 8

[ovrebekk]

Hi 

Jared is currently out in vacation, and I will help out with this case in the mean time. 

I have got your code to build, and setup a separate kit to act as a BLE peripheral with the required ble_app_peer_mac_addr. I can see that my second kit connects to your project, and I can also connect to your project from my phone as a central, but I have yet to see the error that you report. 

All I can see is that if I connect from the phone the advertising stops until I disconnect the phone again. 

Is there a particular sequence I need to follow to reproduce the issue?

Best regards
Torbjørn

[sascha]

Hi Torbjørn,

thank you for help. There's no need to connect to the project with a phone as a central, just let it always advertise. Then power on your second kit and let the two boards to get connected. After that disconnect and connect again the second kit several times (I do it by switching on and off power supply for the second kit). At some point the advertising start function crashes in my project with error 8. For me it usually happens quite fast, only several connect-disconnect cycles to the second kit needed.

Best regards,

Sascha

[ovrebekk]

Hi Sascha

For some reason I can't reproduce it here, I must have tried about 20-30 times (some times just resetting the second kit, other times turning it off for longer). 

Are you running this on a custom board, or a standard DK? 

In case it is a DK, do you have the version number and production date (printed on the large debugging chip on the board)?

Are you logging over RTT or over UART?
The sdk_config.h file has RTT enabled, but it seems you modified the UART settings at one point to change the TX pin. 

Would you be able to capture a sniffer trace when the issue occurs?

If you don't have a professional BLE sniffer available there is a free version provided by us that only requires a devkit:
https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE

Best regards
Torbjørn

[sascha]

It's interesting, because for me it happens often even on the first connect to the second kit. I'm using a custom board, logging over RTT, sdk_config.h is changed to correspond to the custom board pinout. I'll try to reproduce the issue on a standard DK as soon as I'm back in the office in January. If the issue persists on the DK, I'll send a pre-compiled hex file blinking on advertising crash and try to capture a sniffer log.

[ovrebekk]

Hi

Trying to reproduce it on a DK will be valuable, then it's easier to know what to look for. 

If it only happens on the custom board then we should take a closer look at the hardware design. Possibly something like a noisy voltage supply or a misbehaving crystal oscillator could be causing issues for the Bluetooth stack. 

Just let me know when you've had time to look into it. 

Best regards
Torbjørn