NRF_LOG should be disabled for production?

Our product works fine. But I was wondering if we should be completely disabling the NRF_LOG functions for production builds. I suppose it could be using some power and processor time. If so, what is the easiest way to setup a switch so we can easily turn it on for development and off for production. We are using Segger Studio.

And on a related note, the same thing for CLI interface. Should be disabled?

Parents
  • Hello,

    In general, you should disable it for production, yes. Especially if you are using UART for logging/CLI. This draws more power than RTT. 

    Since you are using Segger Embedded Studio (SES), I assume that you are using the nRF5 SDK, and not nRF Connect SDK. Please correct me if I am wrong.

    While it is possible to have one debug and one production configuration in SES, I don't see a very easy way to use this to enable/disable logging. Perhaps if you create a preprocessor definition (or just a normal definition), and then use this to change between two sets of defines in sdk_config.h (at least two sets for the ones that decides whether logging and CLI is enabled or not). 

    You could do something like this near the top of your sdk_config.h:

    #define PRODUCTION_RELEASE 1
    
    
    #if PRODUCTION_RELEASE
        #define NRF_LOG_ENABLED 0
        #define NRF_CLI_ENABLED 0   //don't remember the exact name
    #elif
        #define NRF_LOG_ENABLED 1
        #define NRF_CLI_ENABLED 1
    #endif
    
    ...
    //later in sdk_config:
    
    #ifndef NRF_LOG_ENABLED
    #define NRF_LOG_ENABLED 1   // This will be ignored because NRF_LOG_ENABLED is already defined.
    #endif

    Please note that the file "apply_old_config.h" exists, and that if you use this method to enable/disable drivers, they may be overwritten by that file. This also applies regardless of the define "PRODUCTION_RELEASE".

    Best regards,

    Edvin

Reply
  • Hello,

    In general, you should disable it for production, yes. Especially if you are using UART for logging/CLI. This draws more power than RTT. 

    Since you are using Segger Embedded Studio (SES), I assume that you are using the nRF5 SDK, and not nRF Connect SDK. Please correct me if I am wrong.

    While it is possible to have one debug and one production configuration in SES, I don't see a very easy way to use this to enable/disable logging. Perhaps if you create a preprocessor definition (or just a normal definition), and then use this to change between two sets of defines in sdk_config.h (at least two sets for the ones that decides whether logging and CLI is enabled or not). 

    You could do something like this near the top of your sdk_config.h:

    #define PRODUCTION_RELEASE 1
    
    
    #if PRODUCTION_RELEASE
        #define NRF_LOG_ENABLED 0
        #define NRF_CLI_ENABLED 0   //don't remember the exact name
    #elif
        #define NRF_LOG_ENABLED 1
        #define NRF_CLI_ENABLED 1
    #endif
    
    ...
    //later in sdk_config:
    
    #ifndef NRF_LOG_ENABLED
    #define NRF_LOG_ENABLED 1   // This will be ignored because NRF_LOG_ENABLED is already defined.
    #endif

    Please note that the file "apply_old_config.h" exists, and that if you use this method to enable/disable drivers, they may be overwritten by that file. This also applies regardless of the define "PRODUCTION_RELEASE".

    Best regards,

    Edvin

Children
  • How does this work if the debugger is not connected? Will it still send those LOG to the SWD pins even though its not connected? Or does the Segger compiler automatically ignore those when not building in debug mode?

  • Depending on the log backend it works a bit different:

    For UART:

    If logging is enabled, the nRF will always output the UART log. On the DK, the onboard debugger will pick up these signals, and convert it to USB data, which you can see on your computer. If you disable logging, the nRF will no longer output the UART log.

    For RTT:

    The log is not carried out on any GPIOs. It is written to a dedicated area in the RAM. Then, the debugger will look for this chunk, and continuously read this part of the RAM to look for changes. When changes are detected, it will forward this data over the USB. If you are not debugging, or monitoring the log, then the data will still be written to the same area in RAM, but nothing is detecting this. It doesn't really use that much power, but it does use a lot of RAM and extra flash. 

    When logging is disabled, the log messages are no longer written to RAM. 

    Best regards,

    Edvin

  • Thanks for the clear explanation. Yes it seems that we should disable this extra overhead. I don't think the power consumption is measurable, but if we have any tight timing issues, then the extra clock cycles could be a problem.

Related