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.

[Norbert]

Hi,

Thanks for pointing that out. I will give it a try.

Since my other controller is also slow, I am running the I/F at sleepy 19200bps. Maybe even that is enough for the legacy driver...? But then I know other products with nRF and 3rd party application (I won't name anyone here) which seem to have UART problems even at that speed. So probably not.

Cheers

[Jakub Rzeszutko]

I think you will still observe the problem. Baudrate is not a problem, problem is time between send bytes. The only solution would be to add a delay between send bytes what makes limited sense ;)

Otherwise you need to use proposed library.

[Norbert]

Confirmed, NRF_CLI_LOG_BACKEND = 0 works. Great!

For my small controller, low baudrate helps as it stretches time between RX interrupts. But anyway...

Thanks for your help! I really appreciate the rapidity, quality and professionalism of the responses.

[Norbert]

One more comment (also for the benefit of others): A typical M2M I/F consists of commands, responses and unsolicited events. The latter is giving trouble since there seems to be no way to print to CLI outside a command context. nrf_cli_fprintf hangs after sending a few characters - as documented in the SDK.

So I might have to go back to allowing logs on CLI to send events and simply making sure I do not use logs anywhere else in the code.

[Jakub Rzeszutko]

Reason for not using nrf_cli_fprintf outside of command context is to prevent mixing log print and command print. You shall not observe any "hanging". Basically when log is not active nrf_cli_fprintf can be used without any limitations outside of command context.

Outside command context you shall be able to use this function like that:

nrf_cli_fprintf(&m_cli_uart, NRF_CLI_NORMAL, "test string\r\n");

In addition you can use command **cli echo off** to not send back characters received by CLI. You can also compile such behavior by setting parameter NRF_CLI_ECHO_STATUS to 0 in sdk_config.h file.

[Norbert]

Hmmmm, that's interesting. I just tried this once more and still observe 'hanging'. In fact, the code gets stuck in nrf_cli.c -> cli_write() waiting for tx_rdy to become 1 after having sent about 23 characters:

while (p_cli->p_ctx->internal.flag.tx_rdy == 0)

I thought this had something to do with the preceding comment about using transport_buffer_flush(p_cli).

[Jakub Rzeszutko]

Actually you might be right.

Please add following code:

    transport_buffer_flush(p_cli);

at the end of function nrf_cli_fprintf

[Jakub Rzeszutko]

Other solutions are:

1. Set NRF_CLI_PRINTF_BUFF_SIZE to 1 in sdk_config.

or

2. in file nrf_cli.h change below code

NRF_FPRINTF_DEF(CONCAT_2(name, _fprintf_ctx),                           \
                        &name,                                                  \
                        CONCAT_2(name, _ctx).printf_buff,                       \
                        NRF_CLI_PRINTF_BUFF_SIZE,                               \
                        false,                                                  \
                        nrf_cli_print_stream);                                  \
                        
                    

to 

NRF_FPRINTF_DEF(CONCAT_2(name, _fprintf_ctx),                           \
                        &name,                                                  \
                        CONCAT_2(name, _ctx).printf_buff,                       \
                        NRF_CLI_PRINTF_BUFF_SIZE,                               \
                        true,                                                  \
                        nrf_cli_print_stream);                                  \

By that you will change fprintf parameter autoflush from false to true.

I think that each of these 3 proposals will fix your case

[Norbert]

Not quite there yet...

(1) Changing NRF_CLI_PRINTF_BUFF_SIZE to 1 lets cli_write() hang after 1 character. However, when changing the value to something larger than my largest string size, it works.

(2) No luck, same problem after 23 characters as before.

Anyway, (1) is good enough for me as I do not like to mess with the SDK... ;-)

Thanks!

[Jakub Rzeszutko]

and what about adding: transport_buffer_flush(p_cli); at the end of function nrf_cli_fprintf?

I tested it sucessfully here.