BLE APP CLI example (CLI over BLE UART): poor reliability

[robca]

I'm trying to implement CLI over BLE UART for one of our company projects. I started from the experimental ble_app_cli example in the SDK. I'm using SDK 15.3.0 on the Nordic PCA10056 SDK board. I keep running into instability problems of various kinds.

In order to narrow down the problem, I decided to simply use the example as is, and see if I can reproduce the issues. For the most part, I end up facing the same problems. 

Steps to reproduce:

• start the example in debug mode, so that I can see that's happening.
• connect to the device using an Android BLE Terminal emulator (I use this one https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=en&gl=US)
• see the CLI prompt, send led on and led off commands, it all works
• walk away so that the smartphone loses BLE connection
• at least 50% of the times, the PCA10056 device doesn't get the disconnect event, and the device gets into a state where the BLE stack is not communicating anymore. It's also possible to get into the same state using for example the UART functionality of the nRF Toolbox and sending bogus commands
• I added a NRF_LOG_INFO("BLE Cli enabled");/NRF_LOG_INFO("BLE Cli disabled"); after the nrf_cli_init()/uninit for the BLE CLI in ble_evt_handler(), and I can see that the BLE cli gets initialized but never disconnects/uninits, leaving the stack connected even if the phone is disconnected

Is anyone using the CLI over BLE UART? I know I could implement some sort of watchdog, and that the example is only meant as an example, but the reliability I'm seeing so far makes the use of the CLI over the air a bit questionable. Usually the Nordic examples are a lot more robust than this

What am I doing wrong?

[awneil]

just a thought:

robca said:

Android BLE Terminal emulator (I use this one https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=en&gl=US)

Note that there is no standard for "UART over BLE" - they're all proprietary, manufacturer-specific services.

So how do we know that this app has a reliable implementation of NUS ... ?

[robca]

You are right, we don't... but that app works with every other BLE serial implementation. And, as long as I never lose connectivity, the app works just fine. The connectivity loss is not something the app handles anyway

And, as I said, I can get the example in the same state by simply using the Nordic provided UART applet in nRF Toolbox. In a few cases, even just using the nRF Connect. So that Serial Terminal app is not the real problem, even assuming that is not 100% compatible

[Edvin]

So I tested the .hex file that you sent (together with the softdevice). I tested the SDK15.3.0\examples\ble_peripheral\experimental\ble_app_cli\hex\ble_app_cli_pca10056_s140.hex file, and the unmodified example from the same SDK (both Keil and SES projects) and I still can't reproduce the issue that you report. 

Can you please try to run a debug session, and try to recreate it. Please take a screenshot of the following:

Make sure you get the log window, the call stack and the registers. If you don't see any logging, please try to change 

#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 1
to
#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0

in sdk_config.h. 

Please also upload a screenshot from:

BR,

Edvin

[robca]

I'm not sure how you cannot reproduce it. Did you try with an Android phone or iPhone and losing signal by either moving away or using a metal box? Or are you using the 2 DK setup? I'm pretty sure that the BLE stack being used makes some difference, since I can see slightly different behaviors between Android and iPhone, and it's entirely possible that using an all Nordic stack might change things once more.

Did you try to reproduce with the exact same scenario I provided? If so, can you please let me know what phone/OS version you are using, so that I can see if I can use the same here to get a reproducible scenario for you?

I cannot get a debug session showing anything meaningful, as I already explained many times before. Once it stops working, it stops sending log updates (including the battery updates) and I can only break into the debugger, but never in the example code. It's clearly still running, but in a state where the BLE stack is not responsive to external events. I'm not sure what help would it be to send a ton of screenshots of different parts of the softdevice or other library code

[Edvin]

Yes, I tried with an iPhone, using nRF Connect for iOS, and I walked away (two times) and I put it in a faraday cage (metal box) a handful of times. I used both your provided hex file and the unmodified SDK. 

 

robca said:

I cannot get a debug session showing anything meaningful, as I already explained many times before. Once it stops working, it stops sending log updates (including the battery updates) and I can only break into the debugger

 Can you show me a screenshot of that? Just take a screen dump of SES without doing anything after it stops reporting the battery levels, before you press anything. Perhaps it reveals something I didn't think of asking about. Maybe you see a hardfault?

Is there anything else that can be different from your setup to mine? You are using a standard DK, right? Did you do any modifications to it? What DK version/revision is it? It says on the white sticker.

[robca]

Weird... I have a completely standard PCA10056, no changes. And I can repro it with an iPhone, albeit less reliably than with an Android phone

Unfortunately a family emergency came up, and I will need to focus on that for a few weeks. I won't have access to the development environment either. Can you please close this issue Edvin and once I can focus on this again I will open a new thread and refer to this one. There's no point keeping this pending if you don't have a reliable repro and I cannot work on this. Thanks for all the work on this so far

[Edvin]

I agree it is weird that it is so easily reproducible for you, and not reproducible here. 

I understand. I wish you the best of luck with the family emergency!

I think it is a good idea to start a new ticket when you are back, because I will be off work for some weeks in a few weeks. Please refer to this one, so the Nordic engineer dealing with it have some background information.

Best regards,

Edvin