This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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?

Parents
  • Hi,

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

    regards

    Jared 

  • Here are my projects for the PCA10040 DK.

    8270.ble_app_template.zip

    adv_test_blinky.zip

    ble_app_template.zip is my other peripheral DK project to connect to. It is precompiled 'ble_app_template' example from 'ble_peripheral' folder from SDK 15.0.0 without any modifications.

    adv_test_blinky.zip is project for the main issue, that connects to the other DK. Now when it's advertising, the LED1 is blinking. When advertising crashes, LED1 stops blinking.

    Please, try first hex files from 'Output' directory (both Debug and Release are valid). I'm using it together with s132_nrf52_6.0.0_softdevice.hex.

  • Hi 

    Thanks for sharing the examples. Finally I was able to reproduce the issue. 

    I can reproduce it quite easily if I restart the ble_app_template board while it is connected, forcing a reconnect while the advertising board is running. 

    I believe the issue is related to trying to start advertising while the central is in the process of connecting to the template peripheral. 

    Increasing the link count for the peripheral and central seems to fix the issue, but I need some more time to figure out why this would solve it. 

    Please test this yourself:

    Increase NRF_SDH_BLE_PERIPHERAL_LINK_COUNT in sdk_config.h to 2, increase NRF_SDH_BLE_CENTRAL_LINK_COUNT to 2, and increase the NRF_SDH_BLE_TOTAL_LINK_COUNT to 4. Then run the debugger, and increase the RAM allocation for the SoftDevice accordingly. After that see if you can spot the issue again. 

    Best regards
    Torbjørn

Reply
  • Hi 

    Thanks for sharing the examples. Finally I was able to reproduce the issue. 

    I can reproduce it quite easily if I restart the ble_app_template board while it is connected, forcing a reconnect while the advertising board is running. 

    I believe the issue is related to trying to start advertising while the central is in the process of connecting to the template peripheral. 

    Increasing the link count for the peripheral and central seems to fix the issue, but I need some more time to figure out why this would solve it. 

    Please test this yourself:

    Increase NRF_SDH_BLE_PERIPHERAL_LINK_COUNT in sdk_config.h to 2, increase NRF_SDH_BLE_CENTRAL_LINK_COUNT to 2, and increase the NRF_SDH_BLE_TOTAL_LINK_COUNT to 4. Then run the debugger, and increase the RAM allocation for the SoftDevice accordingly. After that see if you can spot the issue again. 

    Best regards
    Torbjørn

Children
  • I have tried this configuration:

    #define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 2
    #define NRF_SDH_BLE_CENTRAL_LINK_COUNT 2
    #define NRF_SDH_BLE_TOTAL_LINK_COUNT 4

    In this case p_app_ram_start points to 0x200034c0, so I encreased the RAM_START value. For example, I've tried configurations with much more memory allocated to SoftDevice than actually required

    RAM_START=0x20008000
    RAM_SIZE=0x8000

    and


    RAM_START=0x2000C000
    RAM_SIZE=0x4000

    but I still have the issue.

  • Hi 

    It seems I jumped to a conclusion too early, I also see the issue here. 

    Please find my modified version of the example attached: 

    260573_adv_test_blinky_v2.zip

    I updated the example to detect whether or not you try to start advertising while the central is in the process of connecting to a peripheral. 

    If this happens the message "Will crash?" is printed to the log, which seems to occur every time the advertising start fails.

    It is occasionally printed when the advertising starts successfully also.  

    Can you give this a go and see if the problem is always preceded by this message?

    If so it should be possible to change the flow of the program to avoid starting advertising in the middle of a central connection operation. 

    Best regards
    Torbjørn 

  • I've tested your modified example and can confirm that the problem is always preceeded by the "Will crash?" message. Currently, we workaround the issue the same way as you propose by implementing flow control and avoiding peripheral advertising and central connection to another peripheral at the same time. So, there's nothing that keeps us from using the device this way. My intention was just to try to clarify the reason of this behaviour.

  • Hi 

    Thanks for the clarification. Discussing this with the SoftDevice developers they mentioned this is not expected behavior. 

    I have shared your code with them so they can help us look into it, and I will get back to you when they have something to share. 

    Best regards
    Torbjørn

Related