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

BLE shuts off and/or the device stops advertising

After searching around a little bit I found this post, but sadly an answer did never come up apparently. 
I'm using the nrf52 DK, using the 132 Softdevice.

I'm kind of at a loss here and I know it's hard to answer to something like this.
I'm programming an MCU that does communicate with two other devices via I²C and on a timer writes data to the internal flash. An external app can connect, request data and send data to the MCU.

Everything went well for quite some time until last week where the MCU suddenly started to lose connection. The application still works (using sd_write.. sd_delete softdevice API calls to access the flash) after BLE shuts off. LEDs are still blinking when they should blink, but the MCU completely stops advertising, can't be found by any device and will not start again.

To get BLE working again the MCU needs to restart. This happens on the Dev board as on the MCU that I'm working with. 

Any pointer to what I could do is appreciated, like how to reset the BLE, reset the Softdevice or anything that worked for you.

The big problem is that it can't be reproduced reliably, sometimes the MCU will withstand minutes of stress testing without any issue, sometimes the BLE shuts off seconds after the first connection while the MCU does essentially nothing. As this issue came up very far in the development stage it's very hard to find the problem causer. The program stretches upon a multitude of files and thousands of lines of code. Right now I'm willing to accept basically any form of a solution. Getting back BLE would be very nice, especially as it is the only way to communicate with the device, debugging works very poorly while BLE is running. 

I tried to start advertising on a timer, which did nothing. Waiting for quite some time for the MCU to recover on its own. Using a lot of different devices to connect (iPhone, iPad, multiple Android phones) and while testing (the problem occurs very rarely) reading through the code to find the issue (with not prevail so far). 

  • Hi,

    Do you use the Logger module to print debug info to a terminal? If so what do you see? If not I advise you to implement it.

    Do you check the return codes of all your function calls? If not, the typical way of doing it is e.g.:

    uint32_t err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);
    APP_ERROR_CHECK(err_code);

    Can you provide sniffer traces? If you have an extra Nordic dev kit to spare you can use our nRF Bluetooth Sniffer.

  • Thanks for the fast response, I'll try all those things out.

    As of right now, I don't have sniffer traces, so far I used the nRF Connect app do debug the connection (as of now there were no issues, so the app was enough to test things out).

    I'll check the code again and add some error handling where it is missing, thanks for that. 

    The logger module seems nice, especially as it can store crash information to the flash.


  • Happy to help. 

    Since your application seems to just carry on as normal, but without BLE, I suspect that there are some Softdevice API calls (prefixed sd_... ) without error checking. 

  • I figured it out and solved the problem. So for anybody who finds this in the hopes to find an answer:

    The problem was caused by many little things. First one, like MartinBL suggested some of the functions produced error codes that did not get checked, doublecheck your code. Especially if you used some BLE examples to create your code, they usually do not check for anything. It depends on how you test but under the "right" conditions almost every part of the BLE connection can fail, you definitely want to handle every single exception. 

    Second thing: The official Bluetooth connection app and our own app that we used for testing allowed faulty or "dead" BLE connections when rapidly connecting/disconnecting. Without apps running, a BLE connection could be kept active (happened only on Android devices). So it seemed the MCU stopped working but it was actually still connected. 

    Third issue: Something very specific to my case, long story short: a sensor on the MCU completely freaked out when it was exposed to the vibration of a car engine (when taking the thing with me, to the office, home etc). 

  • That is good news! Thank you for the update.