• State Verified Answer
  • Replies 20 replies
  • Subscribers 76 subscribers
  • Views 9208 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 214219
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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!

Parents
  • +1

    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.

  • 0 in reply to jakub

    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.

  • 0 in reply to Jakub Rzeszutko

    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!

  • 0 in reply to Norbert

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

    I tested it sucessfully here.

  • 0 in reply to Jakub Rzeszutko

    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?

  • 0 in reply to Norbert

    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?

  • 0 in reply to Jakub Rzeszutko

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

Reply Children
Related
Terms of service