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

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

Edvin — Thu, 22 Oct 2020 18:04:27 GMT

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

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

robca — Thu, 22 Oct 2020 16:58:27 GMT

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

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

Edvin — Thu, 22 Oct 2020 08:43:34 GMT

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.

[quote user="robca"]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[/quote]

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.

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

robca — Wed, 21 Oct 2020 16:06:47 GMT

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

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

Edvin — Wed, 21 Oct 2020 09:20:04 GMT

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

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

robca — Wed, 21 Oct 2020 00:08:38 GMT

Edvin, I'm not sure what other ZIP file I can send you. I'm using the 15.3.0 SDK, yes. and the ZIP file I previously uploaded contains everything needed to reproduce the problem. You simply need to unzip that file over the SDK 15.3.0 example in examples\ble_peripheral\experimental\ble_app_cli, overwriting the files with the same name. In addition to that, you need to copy the nrf_cli_ble_uart.c file inside the ZIP file over the same file in the SDK in components\libraries\cli\ble_uart. The only other alternative would be to upload the whole SDK, but that's probably too big for the forum

I'm using Segger 4.52a, with the 8.32a CPU support package, but as you can see below, that makes no difference

Here is the HEX file compiled with Release settings, you will also need to flash the S140 softdevice in the SDK 15.3.0 to make it work. Please note that this HEX is actually identical to the SDK example, no change at all (since there is no need to change logs and other for Release, nor MMD). So this hex is pretty much the app portion of the HEX file in examples\ble_peripheral\experimental\ble_app_cli\hex (that one also has the softdevice)

devzone.nordicsemi.com/.../ble_5F00_app_5F00_cli_5F00_pca10056_5F00_s140.hex

So the simplest way to reproduce the problem is simply to flash the examples\ble_peripheral\experimental\ble_app_cli\hex\ble_app_cli_pca10056_s140.hex file onto a PCA10056, connect with an Android device to NORDIC_CLI, then walk away enough to lose signal (or put the phone into a metal box), and the PCA10056 is stuck and never recovers. There's no need to use any parts of my example. So the example, as provided by Nordic, doesn't work reliably

Just in case, my device is a Pixel 3, but I can reproduce it even with an iPhone using the iOS version of nRF Toolbox... for some reason, it takes a bit longer to get the PCA10056 to hang with the iPhone, but it hangs nonetheless. You just need to wait 20 seconds or so once it loses the signal before getting close again to the PCA10056

EDIT: I just tried flashing the examples\ble_peripheral\experimental\ble_app_cli\hex\ble_app_cli_pca10056_s140.hex from SDK 17.0.2 and that one seems to work as expected, and can handle loss of signal, even using the serial terminal app. Unfortunately that doesn't really help us, because we are forced to use SDK15.3.0 (to avoid having to re-validate the entire firmware) and I cannot debug the app flow to understand where it hangs in 15.3.0, and where instead it works in 17.0.2. Also17.0.2 uses a completely different S140 sofdevice, so not much I can learn from this

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

Edvin — Tue, 20 Oct 2020 07:28:40 GMT

I still can't reproduce that. Can you send me:

1: A zipped folder that contains the project file that you used to compile this application that has the issue when you disconnect. Please let me know what IDE you are using (and I assume you are still using SDK15.3.0.

2: The hex file that you are reproducing this with.

BR,

Edvin

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

robca — Fri, 16 Oct 2020 16:03:03 GMT

[quote userid="26071" url="~/f/nordic-q-a/66906/ble-app-cli-example-cli-over-ble-uart-poor-reliability/275280#275280"]you could try to use nRF Connect for Desktop with one of the DKs, and connect to the other DK running your own application. [/quote]

Unfortunately I do not have two DKs. But in any case that would not be a realistic configuration for our scenario where a smartphone will be used to configure the nRF52 device currently under development, and a rugged Android device used to QA test and configure the final product at the end of the production line

I tried with the example as is, no changes, compiled in Release mode, connected the first time using UART in nRF Toolbox. Same problem: as soon as the connection is lost, the PCA10056 gets into a non-working state and never recovers. Neither nRF Connect nor nRF Toolbox can see the device.

The example turns on one of the PCA10056 leds when connected. That led never turns off when the device is in the non-responding state, which probably means that the PCA10056 thinks it's still connected and never even goes into sleep mode. That is consistent with the code never reaching the nrf_cli-uninit() inside BLE_GAP_EVT_DISCONNECTED

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

Edvin — Fri, 16 Oct 2020 08:29:17 GMT

[quote user="robca"]I don't understand what you mean by "disconnect the DK"[/quote]

Ok, I thought that if you had two PCA10056, you could try to use nRF Connect for Desktop with one of the DKs, and connect to the other DK running your own application. Bu "disconnecting the DK" I meant that you could unplug the DK that is running the nRF Connect FW, which would make it immediately unresponsive (similar to what you would see if you walk out of range with a phone). I am still not able to reproduce this.

Does this behavior depend on your sdk_config.h definitions? Does it happen if you use an unmodified SDK and the unmodified example, without any changes to the sdk_config.h file? Or does it only happen when you enable the logging from the CLI module?

BR,

Edvin

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

robca — Wed, 14 Oct 2020 16:02:43 GMT

[quote userid="26071" url="~/f/nordic-q-a/66906/ble-app-cli-example-cli-over-ble-uart-poor-reliability/274852#274852"]Try to sniff the connection. Does the nRF advertise?[/quote]

Thanks Edvin. As I said, the PCA10056 is not working anymore. After losing the signal, I get back to the same desk where the PCA10056 is, and try nRF Connect and/or nRF Toolbox, and there is nothing from the PCA10056 to sniff

I don't understand what you mean by "disconnect the DK". I use the example simply with a single PCA10056 and an Android phone to connect to it. I don't use the very complex Python-script of the test, since that adds unneeded complexity and requires more hardware

In that example, the PCA10056 should work as a BLE UART device, and you can connect to it with any device that can establish a BLE UART connection (e.g. an Android phone using nRF Toolbox UART).

So the PCA10056 is started, an Android phone with nRF toolbox UART used to connect to the PCA10056, walk far enough to lose the connection, then walk back into range. At that point, the PCA10056 is dead

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

Edvin — Wed, 14 Oct 2020 10:37:03 GMT

[quote user="robca"]button at the bottom of the nRF app will say "connecting..." but nothing happens.[/quote]

That can mean that you are too far away, but the phone can't pick up any advertisements. Try to sniff the connection. Does the nRF advertise? Does the phone send a connection request? Does the same thing happen if you try to use nRF Connect, and just unplug the connectivity DK/dongle? This was what I tested. Sorry, but it is a bit difficult for me to walk away from it, because I use Remote Desktop and the DKs are connected to my computer in the office. I tried a couple of times yesterday to just unplug the DK it was connected to (I was using nRF Connect for Desktop). That will cause the connection to time out, because the central disappears, but I never ran into any issues.

BR,

Edvin

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

robca — Wed, 14 Oct 2020 00:30:36 GMT

[quote userid="26071" url="~/f/nordic-q-a/66906/ble-app-cli-example-cli-over-ble-uart-poor-reliability/274572#274572"]You can drag'n'drop them. The easiest would be a zipped folder containing the project folder, which includes all the files you have edited here (main, sdk_config and the project file)[/quote]

Thanks Edvin. I missed that. Glad I asked 🙂

Ok, I tried what you suggested, and the only suggestion that worked well enough was #3, comment out the NRF_LOG calls in cli_ble_uart_write().

The logs don't crash anymore (good!) but I still get into the same state where no connection is accepted. Steps to repro: execute the code in debug mode, connect with nRF Toolbox UART functionality. You will see the <info> app: BLE Cli enabled message. Then walk away until the BLE signal is lost, the button at the bottom of the nRF app will say "connecting..." but nothing happens. The message <info> app: BLE Cli disabled is never reached (even putting a breakpoint there, nothing). If you try to reconnect manually, in the scan screen the Nordic_CLI device doesn't show (because the PCA10056 is in a non working state).There is no way to reconnect to the PCA10056 short of restarting it

Unlike before, you can break into the debugger (assuming you have MMD enabled), but with no real useful information (usually it's in task_yeld())

I'm enclosing all modified files in this ZIP. Please note that I did not follow the exact folder structure of the SDK for the nrf_cli_ble_uart.c file (which you need to manually copy into components\libraries\cli\ble_uart. MMD is enabled on that build, and completely transparent

devzone.nordicsemi.com/.../ble_5F00_app_5F00_cli.zip

Appreciate any help you can provide

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

Edvin — Tue, 13 Oct 2020 10:52:29 GMT

You can drag'n'drop them. The easiest would be a zipped folder containing the project folder, which includes all the files you have edited here (main, sdk_config and the project file).

There is also an option to insert->Image/video/file -> and then click "upload" (which doesn't look like a button after the last update).

However, I will try to do the changes that you did.

I'll try without monitor mode debugging first, because I am not familiar with it.

I see that when I enabled NRF_CLI_BLE_UART_CONFIG_LOG_ENABLED is set to 1, it stops logging after you connect to the device (after the lines saying that notifications are not enabled). I believe the reason for this is that the CLI, which also is a log backend, will log things in the cli_ble_uart_write() function, which is used to process the logs. This means that whenever something is logged, it is queued using NRF_LOG_INFO(), which in turn triggers cli_ble_uart_write(), which triggers the next NRF_LOG_INFO(""); and so on. Hence, since this keeps on adding to the tasks, the idle_task() in main() is no longer called. Try to set a breakpoint there, and you will see that it is not hit after the connection is entered.

So you have 3 choices:

1: set NRF_CLI_BLE_UART_CONFIG_LOG_ENABLED to 0,

2: set NRF_CLI_LOG_BACKEND to 0 (this will stop all logs from being printed over CLI).

3: Remove all calls to NRF_LOG_... in cli_ble_uart_write():

static ret_code_t cli_ble_uart_write(nrf_cli_transport_t const * p_transport,
                                     const void *                p_data,
                                     size_t                      length,
                                     size_t *                    p_cnt)
{
    ASSERT(p_cnt);
    nrf_cli_ble_uart_internal_t * p_instance =
                             CONTAINER_OF(p_transport, nrf_cli_ble_uart_internal_t, transport);
    ret_code_t err_code = NRF_SUCCESS;
    if (p_instance->p_cb->service_started)
    {
        *p_cnt = length;
        err_code = nrf_ringbuf_cpy_put(p_instance->p_tx_ringbuf, p_data, p_cnt);

//        NRF_LOG_INFO("Conn_handle:%d, write req:%d, buffered:%d",
//                                                     p_instance->p_cb->conn_handle, length, *p_cnt);
//        NRF_LOG_HEXDUMP_DEBUG(p_data, *p_cnt);
    }
    else
    {
//        NRF_LOG_INFO("Conn_handle:%d, write req:%d. Notifications not enabled",
//                     p_instance->p_cb->conn_handle, length);
        *p_cnt = length;
        p_instance->p_cb->handler(NRF_CLI_TRANSPORT_EVT_TX_RDY, p_instance->p_cb->p_context);
    }
    return err_code;
}

If you still encounter issues with the disconnection. What does the log say after the disconnect if you implement one of the three workarounds above?

BR,

Edvin

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

robca — Mon, 12 Oct 2020 16:26:55 GMT

[quote userid="6462" url="~/f/nordic-q-a/66906/ble-app-cli-example-cli-over-ble-uart-poor-reliability/274241#274241"]

MMD should work on any Cortex-M (except M0).

You need a J-Link, though; nobody else seems to support it - even ARM themselves!

[/quote]

Yep. I looked into making it work for the STM32 (using JLINK), but I lost interest after a while. I also happened to have found a long dormant bug in the MMD code itself, when FP code is enabled https://forum.segger.com/index.php/Thread/7292-SOLVED-Bug-in-Monitor-Mode-Debug-example-when-using-FP-enabled-code-variable-add/ 🙂

I sure am glad Nordic made it work seamlessly and included the Jlink in the SDK boards

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

robca — Mon, 12 Oct 2020 16:22:21 GMT

[quote userid="26071" url="~/f/nordic-q-a/66906/ble-app-cli-example-cli-over-ble-uart-poor-reliability/274264#274264"]I am trying to reproduce this, but so far without any luck. [/quote]

Thanks for the tests. Here's how to reproduce it, using SDK15.3 (I reproduced it even with the newer SDKs, but our project needs to use SDK15.3, so I hope we can work on that. Otherwise I can create repro steps for 17.0.2, but all the relevant files are identical to 15.3.0)

Use the experimental\ble_app_cli example for PCA10056, and make the following changes to sdk_config.h

#define BLE_NUS_CONFIG_LOG_ENABLED 1
#define BLE_NUS_CONFIG_LOG_LEVEL 4
#define APP_TIMER_KEEPS_RTC_ACTIVE 1  // needed for MMD
#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0  // without this, Jlink RTT doesn't output
#define NRF_CLI_BLE_UART_CONFIG_LOG_ENABLED 1
#define NRF_CLI_BLE_UART_CONFIG_LOG_LEVEL 4
#define NRF_SDH_LOG_ENABLED 1   // this should already be enabled
#define NRF_SDH_LOG_LEVEL 4
#define NRF_SDH_SOC_LOG_ENABLED 1   // this should already be enabled
#define NRF_SDH_SOC_LOG_LEVEL 4

Add the following to main.c (I include the 2 lines preceding the change and the 2 following)

    nrf_cli_ble_uart_config_t config = { .conn_handle = m_conn_handle };

    err_code = nrf_cli_init(&m_ble_cli, &config, true, true, NRF_LOG_SEVERITY_INFO);
    NRF_LOG_INFO("BLE Cli enabled");    // add this line
    APP_ERROR_CHECK(nrf_cli_task_create(&m_ble_cli));

    APP_ERROR_CHECK(err_code);
            
[...]

    m_conn_handle = BLE_CONN_HANDLE_INVALID;
    (void)nrf_cli_uninit(&m_ble_cli);
    NRF_LOG_INFO("BLE Cli disabled");       // add this
    break;

[...]

int main(void)

{
    bool erase_bonds;

#if CONFIG_JLINK_MONITOR_ENABLED                            // enable MMD
    NVIC_SetPriority(DebugMonitor_IRQn, _PRIO_SD_LOW);      // MMD
#endif                                                      // MMD

    core_init();

Make the following changes to ble_app_cli_pca10056_s140.emProject to add the MMD files and to enable it. Also make sure it's debug level 3 and optimization 0. Copy the 3 MMD files under examples\ble_peripheral\experimental\ble_app_cli\pca10056\s140\ses

[...]
<folder Name="Segger_MMD">
  <file file_name="JLINK_MONITOR_ISR_SES.s" />
  <file file_name="JLINK_MONITOR.c" />
</folder>

[...]

<configuration
Name="Debug"
JLinkExecuteCommand="SetMonModeDebug = 1;SetMonModeVTableAddr = 0x31000"
c_preprocessor_definitions="DEBUG;CONFIG_JLINK_MONITOR_ENABLED"
gcc_optimization_level="None" />

Compile and run in debug mode. Connect to the PCA10056 with nRFConnect. You will notice that there is no log output (not even the "BLE CLI enabled" we just added.

Change the following in sdh_config.h to ensure the logs are printed as soon as they happen

#define NRF_LOG_BUFSIZE 2048
#define NRF_LOG_DEFERRED 0

You will see that as soon as you connect to the PCA10056, the program hangs

You can then set again #define NRF_LOG_DEFERRED 1 and add a NRF_FLUSH() after the "BLE CLI enable/disabled" messages to at least monitor connection/disconnection

NRF_LOG_INFO("BLE Cli enabled");
NRF_LOG_FLUSH();

[...]

NRF_LOG_INFO("BLE Cli disabled");
NRF_LOG_FLUSH();

Re-execute the code in debug mode and connect to the PCA10056 with nRF Connect. You will see the "BLE CLI enabled" message. Then disconnect nRF Connect. You will not see a "BLE CLI disabled" message and the PCA10056 is now unreachable by nRF Connect until you restart it

P.S. I cannot find a way to include files. It would be easier for you if there was a way to upload my files, so that you won't have to edit manually

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

Edvin — Mon, 12 Oct 2020 10:53:32 GMT

I am trying to reproduce this, but so far without any luck.

Have you tried adding "DEBUG" to your preprocessor definitions? Does the log say anything when it stops responding then?

Also, can you please try to disable optimization and set a breakpoint on line 91 in app_error_weak.c (after DEBUG is defined in your preprocessor definitions). Is it hit?

What I suspect is that the connection is being used immediately after the connection handle is set to BLE_CONN_HANDLE_INVALID. But this should trigger the error handler, which you should see in the log if DEBUG is defined.

Best regards,

Edvin

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

awneil — Mon, 12 Oct 2020 09:24:24 GMT

MMD should work on any Cortex-M (except M0).

You need a J-Link, though; nobody else seems to support it - even ARM themselves!

https://community.arm.com/developer/tools-software/tools/f/keil-forum/35230/is-monitor-mode-debug-mmd-supported-with-ulink

https://community.st.com/s/question/0D50X00009nNQQnSAO/monitor-mode-debug-mmd-

😞

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

robca — Fri, 09 Oct 2020 22:50:14 GMT

No worries, any help effort is appreciated :) yours would have been a great suggestion, had I not used it already. Discovering MMD was quite a life-changing event, to the point that I miss not having it on other microprocessors (like the STM32 when debugging USB connections, which can also time out WHILE DEBUGGING). Alas, not enough in this case

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

awneil — Fri, 09 Oct 2020 22:46:13 GMT

sorry missed that

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

robca — Fri, 09 Oct 2020 19:50:55 GMT

Thanks for the help, but I'm not sure you actually read what I wrote:

"I tried adding breakpoints (using Monitor mode Debugging to keep the BLE stack alive), but even that didn't lead to any meaningful find: I always get to a point where a call into the Softdevice fails, with no extra information"

I always had Monitor Mode Debugging in all my tests and debug sessions.

The problem is very simple to reproduce: enable the Softdevice, Ble UART and Cli logs and see it freeze as soon as anything connects to the PCA10056

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

awneil — Fri, 09 Oct 2020 18:38:45 GMT

[quote userid="88394" url="~/f/nordic-q-a/66906/ble-app-cli-example-cli-over-ble-uart-poor-reliability/274104#274104"] "break"pause on the debugger, and the code ends in HardFault handler [/quote]

breaking in the debugger is likely to crash the SoftDevice.

Have you tried Monitor Mode Debug?

devzone.nordicsemi.com/.../improved-softdevice-debugging

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

robca — Fri, 09 Oct 2020 16:50:49 GMT

I spent 2 days debugging before creating this thread, yes

Enabling logs completely locks the device when it connects, failing somewhere inside nrf_sdh_ble_evts_poll(). The only way to recover is to "break"pause on the debugger, and the code ends in HardFault handler with no stack trace. I tried even putting a breakpoint in HardFault handler, but it never reaches it before I hit

If I enable fewer logs, I get a lot of "Lost logs - increase log backend queue size", but everything I try to do to fix that (following various suggestions from other threads here" cause only more problems

I tried understanding why the log engine fails, but I went into a maze that keeps leading into the Softdevice dead end. I tried adding breakpoints (using Monitor mode Debugging to keep the BLE stack alive), but even that didn't lead to any meaningful find: I always get to a point where a call into the Softdevice fails, with no extra information

I would appreciate if you found a way to enable logs on that example that allows to understand why be_evt_handler() in main.c is never called with a BL_GAP_EVT_DISCONNECTED when a connection is lost. As I said, I added a couple of NRF_LOG_INFO(_ for connected and disconnected in that handler, disabled the other logs, and I can see that many times the disconnected event is never reached. I could not find a combination of meaningful logs to enable that doesn't lead to a hardfault in the code (which is not to say it's impossible, just that I could not figure it out).

I do understand it's under experimental, but considering it's been "experimental" for at least 2 years, it seems more abandoned than just experimental. In a way that's what makes me wonder how prudent would be to base our OTA configuration strategy on the BLE UART CLI, given it seems to be a non-supported component. If even an example as simple as that one fails so badly (unrecoverable without a reset), adding CLI to a much more complex project, with multiple VS UUIDs seems to be looking for problems

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

Edvin — Fri, 09 Oct 2020 14:20:12 GMT

[quote user=""]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.[/quote]

Have you tried debugging this issue? Does the log from the nRF52840 say anything at this point?

The example is located in the experimental folder, so it may not be properly tested.

BR,

Edvin

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

robca — Thu, 08 Oct 2020 20:12:27 GMT

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

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

awneil — Thu, 08 Oct 2020 20:08:05 GMT

just a thought:

[quote userid="88394" url="~/f/nordic-q-a/66906/ble-app-cli-example-cli-over-ble-uart-poor-reliability"]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)[/quote]

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 ... ?