How to debug configuration issues?

[Torsten Robitzki]

Hi,

I have a concrete example, where I have no clue, as to why a given configuration is not working. In general, I wonder, how one is supposed to debug / investigate such, quite time consuming issues.

I want to add RTT logging to a MCUBoot bootloader. Here is the configuration, that according to the available documentation (https://docs.nordicsemi.com/bundle/ncs-2.7.99-cs2/page/nrf/test_and_optimize/logging.html) should work:

Fullscreen

1

2

CONFIG_LOG=y

CONFIG_LOG_BACKEND_RTT=y

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y

This results in this warning:

Fullscreen

1

2

3

4

5

6

7

warning: LOG_BACKEND_RTT (defined at subsys/logging/backends/Kconfig.rtt:4) was assigned the value

'y' but got the value 'n'. Check these unsatisfied dependencies: USE_SEGGER_RTT (=n),

(!LOG_MODE_MINIMAL) (=n). See

http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOG_BACKEND_RTT and/or look up

LOG_BACKEND_RTT in the menuconfig/guiconfig interface. The Application Development Primer, Setting

Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful

too.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

warning: LOG_BACKEND_RTT (defined at subsys/logging/backends/Kconfig.rtt:4) was assigned the value
'y' but got the value 'n'. Check these unsatisfied dependencies: USE_SEGGER_RTT (=n),
(!LOG_MODE_MINIMAL) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOG_BACKEND_RTT and/or look up
LOG_BACKEND_RTT in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

I think, I understand that warning and applying it to my configuration yields this:

Fullscreen

1

2

3

4

CONFIG_LOG=y

CONFIG_LOG_BACKEND_RTT=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_LOG_MODE_MINIMAL=n

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_MODE_MINIMAL=n

But still, this results in a warning, that `LOG_BACKEND_RTT` got the value `n`, even though, `LOG_MODE_MINIMAL` is set to y.

Fullscreen

1

2

3

4

5

6

warning: LOG_BACKEND_RTT (defined at subsys/logging/backends/Kconfig.rtt:4) was assigned the value

'y' but got the value 'n'. Check these unsatisfied dependencies: (!LOG_MODE_MINIMAL) (=n). See

http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOG_BACKEND_RTT and/or look up

LOG_BACKEND_RTT in the menuconfig/guiconfig interface. The Application Development Primer, Setting

Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful

too.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

warning: LOG_BACKEND_RTT (defined at subsys/logging/backends/Kconfig.rtt:4) was assigned the value
'y' but got the value 'n'. Check these unsatisfied dependencies: (!LOG_MODE_MINIMAL) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOG_BACKEND_RTT and/or look up
LOG_BACKEND_RTT in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

Beside the question, whether this should work or not, how should we debug such issues to find working configurations? Obvious starting point, is probably the mentioned definition of `LOG_BACKEND_RTT`:

Fullscreen

1

2

3

4

5

6

config LOG_BACKEND_RTT

bool "Segger J-Link RTT backend"

depends on USE_SEGGER_RTT

default y if !SHELL_BACKEND_RTT

select SEGGER_RTT_CUSTOM_LOCKING

select LOG_OUTPUT

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

config LOG_BACKEND_RTT
	bool "Segger J-Link RTT backend"
	depends on USE_SEGGER_RTT
	default y if !SHELL_BACKEND_RTT
	select SEGGER_RTT_CUSTOM_LOCKING
	select LOG_OUTPUT

I don't even see a dependency on `LOG_MODE_MINIMAL` in that code. Is it possible to somehow capture the call to the configuration parser and add some switches for more verbosity here? Are there other strategies to debug such issues?

(Version, nrf-connect v2.7.99-cs2, Target: nRF5340)