Logging in nRF Connect SDK

nRF Connect SDK provides a logging system that offers different logging possibilities for testing and debugging. The system is multilevel, meaning that it can be enabled and configured independently for different modules. This allows you to choose the logging information you want to receive and how it should be gathered. Several logging backends allow for defining the interface and protocol used for gathering logging messages.

You can obtain logging information from the following sources:

  • Custom applications

  • Network protocol applications

  • Samples, drivers, and libraries

  • Zephyr system kernel

For example, you can gather logging information about network events from network protocol applications and logging information about threads from Zephyr system kernel at the same time.

This flexibility comes at a cost: the system’s complexity requires different approach to configuration for single components and backends. See the following sections for more information.

Zephyr system logger

Zephyr allows you to configure log levels independently for each module and also offers many general logger engine options, for example default levels, discarding messages, overflow behavior, and more. You can use the Zephyr system logger in nRF Connect SDK for the following use cases:

  • Internal system logs - Useful for analyzing detailed system performance, for example issues with threads stack sizes.

  • Logs from external components - Useful for gathering messages from sample applications and custom modules.

The logger can be enabled with the CONFIG_LOG Kconfig option. This option is automatically set alongside the minimal logging implementation (CONFIG_LOG_MINIMAL) with the CONFIG_NCS_SAMPLES_DEFAULTS Kconfig option, which is enabled by default for all samples in nRF Connect SDK. For more information about configuring Zephyr’s logger, see Logging.

Network protocol application logging

In nRF Connect SDK, network protocol applications are using separate threads of the Zephyr system. Each one of these threads can use its own logging module. For this reason, each must be configured individually.

Thread

As a result of being able to work as a bare metal application, OpenThread uses its own internal logging module for printing messages. The OpenThread logger offers several configuration options that can be used to select log levels, regions, output methods, and more. For detailed information about available options and API, visit OpenThread logging.

In nRF Connect SDK, OpenThread runs as a Zephyr system application, meaning that it can be configured by setting options in the system configuration file, without modifying the source code. For details about how to configure OpenThread logger in nRF Connect SDK, see OpenThread stack logging options.

Zigbee

Zigbee stack logs are independent from Zephyr system logger and must be configured by setting dedicated options in the system configuration file. For detailed information, see Custom logging per module.

Logging backends

Logging backends are low-level drivers that can be configured to work with hardware interface for sending log messages. You can enable many backends at once and make them work simultaneously, if you want to gather the same kind of information from different sources.

Tip

As a recommendation, avoid selecting many backends using the same physical interface instance to avoid mutual interference. For example, instead of UART0 for both, choose UART0 for one backend and UART1 for another.

UART

The UART interface can be configured as a logging backend using the following Kconfig options:

For information about how to see UART output, see How to connect with PuTTY.

RTT

SEGGER’s J-Link RTT backend logging can be handled with the following Kconfig options:

For information about how to run SEGGER’s J-Link RTT on your PC and see the logs, see How to use RTT.

Spinel

Using Spinel protocol as a logging backend is specific to OpenThread’s Network Co-Processor (NCP) architecture. The Spinel protocol can be configured as a logging backend using the following Kconfig options:

To communicate using the Spinel protocol and gather logs, you need one of the following tools:

Each one of these tools accepts the -d <DEBUG_LEVEL> and --debug=<DEBUG_LEVEL> arguments, which can be used to display logging messages. See PySpinel arguments for an example if you are using PySpinel. Alternatively, see wpantund Usage Overview for information about how to change wpantund configuration file to avoid passing arguments manually every time.

Shell

When you enable Zephyr’s Shell, it by default becomes a logging backend. You can disable this backend by using the following Kconfig option:

Note

The UART and RTT logging backends can also be configured as shell backends. For example, if the UART backend is disabled, but UART is selected as the shell backend and Zephyr’s shell is enabled as the logging backend, the logging output will end up in UART.

Logging output examples

See the following examples of different sample logs available in nRF Connect SDK:

  • Minimal Zephyr logs

    D: Debug message
I: Info message
W: Warning message
E: Error message

  • Full Zephyr logs

    [00013022] <dbg> sample_app: Debug message'
[00013023] <inf> sample_app: Info message'
[00013023] <wrn> sample_app: Warning message'
[00013023] <err> sample_app: Error message'

  • OpenThread logs

    -CORE----: Notifier: StateChanged (0x00000040) [Rloc-]
-MLE-----: Send Parent Request to routers (ff02:0:0:0:0:0:0:2)
-MAC-----: Sent IPv6 UDP msg, len:84, chksum:1e84, to:0xffff, sec:no, prio:net