UART and RTT transports for logging and CLI

[Norbert]

Hello,

I am trying to get CLI working over UART and simultaneously use RTT for logging. I don't quite get my head around this. My platform is the nRF52840 DK. I am using Segger as IDE.

I started with the CLI example making sure that that only UART transport is defined for CLI (NRF_CLI_RTT_ENABLED 0 and NRF_CLI_UART_ENABLED 1). Prints to CLI are via nrf_cli_fprintf().

For configuring logging, I am using NRF_LOG_ENABLED 1, NRF_LOG_BACKEND_RTT_ENABLED and NRF_LOG_BACKEND_FLASH_ENABLED 0 (not needing/wanting Flash log at this point). Logging is done with the NRF_LOG_INFO() macro.

In my understanding, RTT is using SWD as physical transport which the DK's MCU makes somehow accessible over the USB. UART should be mapped to the VCOM. Both transports should be independent of each other.

Now I would expect that logs appear only in the 'Debug Terminal' console (or the RTT J-Link panel, channel 0, integrated in Segger) and that I can use the CLI over VCOM. However, while CLI is only accessible over the UART, all logs are sent to the debug terminal *and* the UART (I checked with a logic analyser). Is there any reason for this? What am I missing here?

Thanks!

[jakub]

But what is not working as you expect?

CLI apart from being command line interface it also resposible for printing logs. This was an intention when Nordic implemented new CLI.

What is more you can configure via CLI what logs are you interested in. Basically you can filter them in runtime. For that purpose you can use commands: `log status` to check what Log are active, and you can use `log enable` or `log disable` commands to deactivate logs you don't need at the moment. By using 'log enable' command you can also configure what level of log you are interested in. For instance only logs on error level.

[Norbert]

Hi Jakub,

Thanks for the response. So probably nothing is wrong at all.

I did not know about Nordic's intention when implementing the CLI. I thought log and CLI were two completely separate modules and could hence be routed to separate interfaces.

I thought about using the CLI as ASCII-based M2M interface and have human-readable logs on another I/F. As the M2M should not be cluttered with logs, it seems I have to do the M2M I/F implementation the old way - no convenient shortcut here (pity).

Thanks.

[Jakub Rzeszutko]

Hi Norbet,

I am not sure why you do not want to have logs combined with the CLI? It is not a problem at all to print logs and enter commands either M2M or H2M.

Nevertheless CLI is "only" one of logger backends and this backend can be simply switched off. As a results you will have pure CLI. We tried to prepare as flexible code as possible.

[Norbert]

Hi Jakub,

That is interesting. How do you disabled logs on the CLI to get pure CLI?

The reason for not wanting to have logs together with the CLI is twofold:

1. The poor controller on the other end of the link is small and slow and will have trouble doing its normal work when being bombarded with logs. All log strings need to be parsed first to be identified as irrelevant.

2. Unfortunately, the protocol used does not allow for any 'comment' strings, i.e.everything received is interpreted as command and acted upon.

Thanks and best regards.

[Jakub Rzeszutko]

Hi,

Logs deactivation is pretty easy, you need to set to 0 parameter: NRF_CLI_LOG_BACKEND in sdk_config.h file.

However shortly you will face another problem that CLI is able to receive hand typed commands but not commands send by external device. It is weakness of our UART driver which is not fast enought. For such case we have prepared dedicated library called lib_uarte.

We have prepared an example for people who want to use CLI with external device / script (your scenario). It is proven in the battle:

nrf5\examples\peripheral\experimental_cli_libuarte