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

how to enable NCS RTT logging?

I'm following the NCS tutorials. I'm targeting the 52840 on the 9160DK board. I'm using SES with NCS1.6.

I'm able to get the hello world to run and the message is out on the serial port. Now I'd like to have RTT for logging but I found it's very confusing to how to get it to work.

I used Project->Config NCS project to enable the RTT option. I'm not sure if this is the only thing needed. Probably not because it doesn't work. I saw others also modify prj.conf to include various options but it doesn't seem conclusive as to what are the necessary changes. They all look different.

I'm wondering if there are tutorial or documents to:

1. how to enable RTT

2. how the logger works in general.

3. How does the configuration (ie KConfig) work? Should I just use SES for that or also need to edit the prj.conf?

Thanks!

My main() is like this:

#include "logging/log.h"

LOG_MODULE_REGISTER(main);

void main(void)
{
    LOG_INF("Hello World!\n");
}

As to the hardware, I assume it works through the same interface chip on the 9160DK, without needing a dedicated JLink?

  • Hi,

    For general information about the logger module I recommend Zephyr's documentation. Particularly: Logging.

    Zephyr also has some information about Kconfig, but my general recommendation is to use prj.conf for all options you want set "permanently", and to use the configuration tool in SES, guiconfig and menuconfig if you want to search for an option, debug some Kconfig issue, or don't need the option you set to be permanent.

    The reason for why I recommend using prj.conf is that the other tools stores the result in the build folder, which means that if you delete the build folder or do a pristine build, the configuration will be lost.

    To enable logging over RTT, you must set these two options:

    CONFIG_USE_SEGGER_RTT=y
    CONFIG_LOG_BACKEND_RTT=y

    And yes, RTT works over the onboard debugger on the nRF9160 DK. No need for extra hardware.

    Best regards,

    Didrik

  • I tried what you suggested but it still doesn't work. My prj.conf contains only the two lines you suggested.

    When I open the Segger RTT Viewer, it is able to connect but no messages. If I open the "Channel Info" menu it actually shows the correct info about the RTT buffer. So this makes me believe the RTT part is actually OK. It's the logger part that's not working. Can you tell me the few line sin my main() is sufficient to trigger the output to RTT? Is there any other config or init needed? I'm still reading the logging document. I haven't found anything seemingly related.

    Back to the configuration(KConfig) process. It's still very confusing. If I only have those 2 lines in the prj.conf and start a clean build, does SES automatically provide a set of default configuration for everything else? Is it part of SES?

    Also, how can I save the SES solution so that I can open it next time, instead of using "Open NCS project:" and have to set all those options over and over?

    Thanks!

  • bluebeam said:
    My prj.conf contains only the two lines you suggested.

     Sorry, I misunderstood, and thought that you already had gotten logging to work (over UART).

    To enable logging in general, you need to set CONFIG_LOG=y.

     

    bluebeam said:
    Back to the configuration(KConfig) process. It's still very confusing. If I only have those 2 lines in the prj.conf and start a clean build, does SES automatically provide a set of default configuration for everything else? Is it part of SES?

     Config options can come from a few places. First is the various Kconfig files spread around the SDK (typically one per library). They define the options, and their default values. They can also specify dependencies, make the option become enabled automatically if another option is set, or set some other option when the option is set.

    Next in the chain are defconfig files. These can be found in the board and soc folders, and changes some options for that board/soc.

    After that comes the prj.conf file which is the project's configuration file.

    All these configuration options gets collected into <build folder>/zephyr/.config. From there, a C header file is generated with the options as precompiler macros.

    When you use menuconfig, guiconfig or SES's configuration tool, you are working on the .config file directly. Therefore, if you ever delete your build folder (a pristine build), you will lose any configurations set with those tools.

    It is therefore recommended that you use prj.conf for any options you want set for more than just one build.

    You should also note that SES is not able to detect changes to the prj.conf file after your have opened the project. Therefore, you must either re-open the project, or use 'Project -> Run CMake...' for the changes to take effect.

     

    bluebeam said:
    Also, how can I save the SES solution so that I can open it next time, instead of using "Open NCS project:" and have to set all those options over and over?

     Unfortunately, I don't think that is possible.

  • I finally figured that out. The logger is a Zephyr thread. (It could be configured as non-thread too. I'll save that exercise for another day.) To make sure the logger thread have a chance to run and work, I'll need to call sleep. So the main() looks like this:

    LOG_MODULE_REGISTER(main, LOG_LEVEL_INF);
    
    void main(void)
    {
      while(1){
        LOG_INF("Hello World!\n");
        k_sleep(K_MSEC(100));    
      }
    }

    It's probably not the best way to structure main() but I just want to get my Hello World out and move on. It's good enough for now.

  • Hi, it good to hear that you got it working.

    However, it should not be necessary to call k_sleep to let the logging thread run.

    First, when you reach the end of main, it should be able to switch to the logging thread. But also, if you use the default thread priorities, the main thread is preemptible, so unless the logging thread has a lower priority, it should be able to run.

    For reference, here is the application I used to test your problem: minimal_log.zip

Related