This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Regarding logging concepts in nrf connect SDK

Hi Nordic Team,
    
                I am new to embedded developing and I am learning about logging data while working on  nRF connect sdk" .
                kit:nrf5340
                SDK: nRF connect SDK v1.5.0
             
              
1. What is the configuration I need to add in prj.conf file , to print a message  LOG_INFO("in main function");
2. In some examples they have included LOG_MODULE_DECLARE() after including log.h file in source code.
    And in some examples BT_LOG is also used, what is the primary difference between LOG and BT_LOG ? .
3. I could find various log levels such as (info,warning debug,etc), Are these used to log through UART or they can be logged in the peer device
4. Is there any example in nrf connect SDK explaining all log based concepts.
5. Can you please tell me is there any link in nRF connect SDK explaining log based concepts  .I would like to know the function of the below log cases and the mode in which it is enabled.
              a) BT_INF
              b)BT_DBG
              c)BT_LOG
              d)BT_WARN
              e)BT_INFO
              
             
  • 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-L19Logging 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

Related