Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Click or drag files to this area to upload. You can upload up to 2 files.

Exercise 3

v2.x.x

Exploring the logger module features

In this exercise, we will practice configuring a software module using Kconfig configuration options. We will use the logger module as a case study and experiment with some of its features.

When the logger module is enabled by setting the global configuration symbol CONFIG_LOG=y, the following logger configurations are enabled by default.

OptionDescription
LOG_MODE_DEFERREDDeferred mode is used by default. Log messages are buffered and processed later. This mode has the least impact on the application. Time-consuming processing is deferred to the known context.
LOG_PROCESS_THREAD A thread is created by the logger subsystem (deferred mode). This thread is woken up periodically (LOG_PROCESS_THREAD_SLEEP_MS) or whenever the number of buffered messages exceeds the threshold (LOG_PROCESS_TRIGGER_THR).
LOG_BACKEND_UARTSend logs to the UART console.
LOG_BACKEND_SHOW_COLORPrints errors in red and warnings in yellow. Not all terminal emulators support this feature.
LOG_BACKEND_FORMAT_TIMESTAMPTimestamp is formatted to hh:mm:ss.ms,us.
LOG_MODE_OVERFLOWIf there is no space to log a new message, the oldest one is dropped.
Default options when enabling the logger module

Let’s verify this by invoking nRF Kconfig GUI.

This is accessible from the ACTIONS menu:

The logger module is found under the menu Sub Systems and OS Services as shown in the figure below:

Default configurations enabled with CONFIG_LOG

These default settings are set by the nRF Connect SDK through Kconfig definition files (covered in Lesson 3). We can overwrite the default settings using the application configuration file prj.conf as we will see in this exercise.

Exercise steps

1. In the GitHub repository for this course, open the base code for this exercise, found in lesson4/fund_less4_exer3 of whichever version directory you are using (v2.x.x or v1.6.0-v1.9.1).

This code is identical to the one in the previous exercise.

2. For the sake of demonstration, let’s disable CONFIG_LOG_BACKEND_SHOW_COLOR.

This is done by adding the following configuration line into the application configuration file prj.conf.

Since the application configuration file has the highest precedence, it will override the default settings and disable this feature.

3. Build the exercise

You can confirm that this feature has been disabled by opening Kconfig and typing LOG_BACKEND_SHOW_COLOR in the search bar. You can see that the “Colors in the backend” box is unchecked and this feature has been disabled.

LOG_BACKEND_SHOW_COLOR has been disabled

4. Flash the application to the board as we have done in previous exercises. You should notice that the error and warning messages are no longer colored.

Log output with LOG_BACKEND_SHOW_COLOR disabled

5. Let’s try another feature of the logger module.

CONFIG_LOG_MODE_MINIMAL enables a minimal logging implementation.

This is very useful when you have limited memory, and are not in need of the deferred feature of the logger. It has very little memory footprint overhead on top of the printk() implementation for standard logging macros. There are no timestamps, prefixes, colors, or asynchronous logging, and all messages are processed in-place which simply means it is sent to the console just like we did with printk().

Once CONFIG_LOG_MODE_MINIMAL is enabled, most other logger configurations will be unavailable, i.e they will have no effect.

Add the following configuration line into prj.conf

6. Build the exercise and flash it to the board.

Notice that the output of the logger module is significantly different when the minimal mode is activated.

Logger module output in minimal mode

Log levels are now indicated by letters (D=Debug, I=Info, W=Warning, E=Error) and timestamps and prefixed module names are not displayed.

The solution for this exercise can be found in the GitHub repository, lesson4/fund_less4_exer3_solution of whichever version directory you are using (v2.x.x or v1.6.0-v1.9.1).

v1.6.0 – v1.9.1

Exploring the logger module features

In this exercise, we will practice configuring a software module using Kconfig configuration options. We will use the logger module as a case study and experiment with some of its features.

When the logger module is enabled by setting the global configuration symbol CONFIG_LOG=y, the following logger configurations are enabled by default.

OptionDescription
LOG_MODE_DEFERREDDeferred mode is used by default. Log messages are buffered and processed later. This mode has the least impact on the application. Time-consuming processing is deferred to the known context.
LOG_PROCESS_THREAD A thread is created by the logger subsystem (deferred mode). This thread is woken up periodically (LOG_PROCESS_THREAD_SLEEP_MS) or whenever the number of buffered messages exceeds the threshold (LOG_PROCESS_TRIGGER_THR).
LOG_DETECT_MISSED_STRDUPAssert and log error messages when the logger detects a local string format specifier (%s) and string address that is not from the read-only memory section and not from the pool used for string duplicates.
LOG_BACKEND_UARTSend logs to the UART console.
LOG_BACKEND_RTTSend logs to the RTT console. Note that by default the logger sends output to two consoles.
LOG_BACKEND_SHOW_COLORPrints errors in red and warnings in yellow. Not all terminal emulators support this feature.
LOG_BACKEND_FORMAT_TIMESTAMPTimestamp is formatted to hh:mm:ss.ms,us.
LOG_MODE_OVERFLOWIf there is no space to log a new message, the oldest one is dropped.
Default options when enabling the logger module

Let’s verify this by invoking guiconfig. The logger module is found under the menu Sub Systems and OS Services as shown in the figure below:

Default configurations enabled with CONFIG_LOG

These default settings are set by the nRF Connect SDK through Kconfig definition files (covered in Lesson 3). We can overwrite the default settings using the application configuration file prj.conf as we will see in this exercise.

Exercise steps

1. In the GitHub repository for this course, open the base code for this exercise, found in lesson4/fund_less4_exer3 of whichever version directory you are using (v2.x.x or v1.6.0-v1.9.1).

This download is identical to the one in the previous exercise.

2. For the sake of demonstration, let’s disable CONFIG_LOG_BACKEND_SHOW_COLOR.

This is done by adding the following configuration line into the application configuration file prj.conf.

Since the application configuration file has the highest precedence, it will override the default settings and disable this feature.

3. Build the exercise

You can confirm that this feature has been disabled by opening guiconfig and examining the Output Formatting submenu in the Logging menu. You should see that the Enable colors in the backend is unchecked now.

LOG_BACKEND_SHOW_COLOR has been disabled

4. Flash the application to the board as we have done in previous exercises. You should notice that the error and warning messages are no longer colored.

Log output with LOG_BACKEND_SHOW_COLOR disabled

5. Let’s try another feature of the logger module.

CONFIG_LOG_MODE_MINIMAL enables a minimal logging implementation.

This is very useful when you have limited memory, and are not in need of the deferred feature of the logger. It has very little memory footprint overhead on top of the printk() implementation for standard logging macros. There are no timestamps, prefixes, colors, or asynchronous logging, and all messages are processed in-place which simply means it is sent to the console just like we did with printk().

Once CONFIG_LOG_MODE_MINIMAL is enabled, most other logger configurations will be unavailable, i.e they will have no effect.

Add the following configuration line into prj.conf

6. Build the exercise and flash it to the board.

Notice that the output of the logger module is significantly different when the minimal mode is activated.

Logger module output in minimal mode

Log levels are now indicated by letters (D=Debug, I=Info, W=Warning, E=Error) and timestamps and prefixed module names are not displayed.

The solution for this exercise can be found in the GitHub repository, lesson4/fund_less4_exer3_solution of whichever version directory you are using (v2.x.x or v1.6.0-v1.9.1).

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.