RE: Regarding logging concepts in nrf connect SDK

Heidi — Thu, 22 Apr 2021 09:19:16 GMT

Hi!

We have the page Logging in nRF Connect SDK and the Logging API in Zephyr.

First off, you can select different logging backends: UART, RTT, Spinel or Shell. UART logging backend uses the UART interface to send the logging information. RTT backend uses SEGGER's JLink Real Time Transfer (RTT) and requires a J-Link device (the nRF9160DK has this) and is very practical because, as opposed to the UART backend, it doesn't occupy an UART instance in your application. I'm not that familiar with Spinel, but it's specific to OpenThread's NCP and RCP architectures so it might not be relevant for you. Enabling Zephyr's Shell automatically makes it a logging backend. The Zephyr Shell is a module in Zephyr similar to the Unix shell with certain features that you are listed in the documentation.

The UART and RTT logging backends can also be configured as shell backends.

The minimal configuration you need to enable logging is CONFIG_LOG. Then you can use the function LOG_INF(), as long as you make sure CONFIG_LOG_DEFAULT_LEVEL is 3 or larger, so the module will print LOG_INF() messages and other "less severe" log messages as well (see zephyr/subsys/logging/Kconfig.filtering L22-L26 for the different levels).

All samples in NCS has the configuration CONFIG_NCS_SAMPLES_DEFAULTS enabled by default, which selects both CONFIG_LOG and CONFIG_LOG_MINIMAL.

2. Modules that are split up over multiple files must have exactly one file use LOG_MODULE_REGISTER() to create module-specific state and register the module with the logger core. The other files in the module should use LOG_MODULE_DECLARE() instead to declare that same state. Otherwise, the functions LOG_INF() etc. will not be able to refer to module-specific state variables. So unless you're writing your own module, you don't need to consider this macro.

BT_LOG refers to the specific module with the name "BT, see zephyr/subsys/bluetooth/Kconfig L17-L19. Logging in a module explains how logging configurations are created from module names. So BT_LOG enables logging for the specific module.

3. The different levels can be used regardless of which logging backend you are using.

4. There are no samples explaining the logging, but the documentation I provided at the beginning of my comment contains a lot of information.

5. CONFIG_BT_LOG_LEVEL will decide which of those commands (1 LOG_ERR(), 2 LOG_WRN(), 3 LOG_INF(), 4 LOG_DBG()) in the BT module will be filtered out. So for instance LOG_LEVEL 2 will only include logging information 1 LOG_ERR() and 2 LOG_WRN().

Let me know if that answered your questions!

Best regards,

Heidi