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]

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.

[Norbert]

Doesn't work for me. Note that the SW gets stuck *during* the very first fprintf, i.e. it never gets to the end of the function.

Stupid question: Have you made sure that the string you are sending is larger than 23 characters?

[Jakub Rzeszutko]

I am not sure if I understand what are you asking. Basically flush functionality was implemented to limit number of accesses to UART peripheral.

Module nrf_fprintf (sdk\nrf5\external\fprintf) has internal counter which monitors number of bytes in the buffer. If limit is reached string is send via UART and further bytes are again collected in the buffer. It is realized by function buffer_add in file nrf_fprintf_format.c

nrf_cli is using nrf_fprintf module and by default it sets "string buffer" to 23 bytes.

I am a bit supprised that setting autoflush to true did not work for you (2). Are you sure that you have rebuild the project?

[Norbert]

Sorry if I wasn't clear. I meant when testing, you need to make sure that your fprintf sends more than 23 characters. But I am sure you did that.

I retested once more and made sure the build was cleaned before. No change in behaviour. I am a bit lost here...