Confusion between configuration files NrfConnect SDK: KConfig vs KConfig.defaults vs KConfig interactive gui vs prj.conf

[uzer123]

I'm new to nrf connect sdk and although i studied the documentation its not completely clear to me.

What is the difference between KConfig vs KConfig.defaults vs prj.conf vs KConfig interactive gui?

My understanding till now is (looking to nrf5340 audio dk example):

KConfig: a file in app root folder (optional) where you can define your own configuration options and their default values (like NRF5340_AUDIO_TRANSPORT_MODE)

KConfig.defaults: a file in app root folder (optional) where there are more DK related configuration options and their default values (in contrast with KConfig that is more application focused like I2C)

If you change one of the two the configuration is saved in the temp file /zephyr/.config and you can build (not pristine?) again and flash after each change.

KConfig interactive gui: a GUI that helps you pick the KConfig (and KConfig.defaults, as it is included in KConfig) options and each change is temporary saved in /zephyr/.config. It takes its options from KConfig (but why my own KConfig in the app folder is not included?)

prj.conf: a file where you write the options you want to change using the CONFIG_name_from_KConfig file and each change is permanent to your build. You have to make pristine build and flash after each change

So, this is what i understand but i would like a validation..

[Raoul]

Hi Uzer, sounds like you've understood just about everything correctly.

I should point out that prj.conf is by far the file you'll be dealing with the most often - it is not only used to configure your own user-defined Kconfig options, but to configure any of the thousands of options that NCS exposes. When you experiment with kconfig options through an interactive interface, prj.conf is where you'll set them permanently (and I personally just forego the interactive interfaces and experiment by changing prj.conf directly).

It shouldn't always be necessary to do a pristine build when changing prj.conf, the build system should figure out what to rebuild. But it doesn't always get things right, so if you encounter issues, pristine builds could definitely be necessary. But as you might have noticed, they take longer to complete.

Note that instead of the KConfig interactive GUI in the VS Code extension, you can also opt to use the guiconfig or menuconfig interfaces: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/build/kconfig/menuconfig.html

The VS Code extension lets you select which interactive interface you want to use, in a dropdown menu.

Just to be clear, building and flashing are completely independent steps, flashing is not related to the Zephyr build process and so these configuration files are not affected by flashing, just building.

kconfig.defaults is actually something I haven't encountered before. So outside of the audio dk, it's not something you'll usually have to worry about.

I hope this adds to your understanding.

Best regards,

Raoul

[uzer123]

Thanks for your answer. It adds value to my understanding and agrees with what i've seen so far dealing with Nrf Connect. 

So, in a nutshell the TL;DR answer is:

You can use Kconfig gui/guiconfig/menuconfig GUIs to take ideas about the possible configurations but if you want to try or have a permanent configuration find the appropriate name from the GUIs (or the Kconfig search engine you sent) and add it to prj.conf. Then make a build or if you are afraid that your configuration didn't work, try a pristine build. IF you want to add your own options for configuration (for example include your own library/src file with default values) you can make your own Kconfig file (no file extension) in apps root folder as nicely described in nRF Connect SDK Fundamentals course Lesson 3, exercise 2.

[Raoul]

That is entirely correct! This is a good TL;DR for a majority of your Kconfig needs. To add to your understanding, you could also look at the role of _defconfig files that define the default prj.conf settings for a particular board, and at the ability to use different .conf files for different build targets.

What I also find very useful sometimes is to look at autoconf.h, located in the build/zephyr/include folder (after building) - it is the end result of all the merged configuration files and helps make clear exactly what is and isn't enabled at any particular time for the application you've compiled.

In general Kconfig is quite well documented in NCS/Zephyr. I'll leave you with the following two articles:

Setting Kconfig configuration values

Kconfig - Tips and Best Practices

Best regards,

Raoul

[uzer123]

Yes, these sources are very good addition to more understanding or/and better modification of available settings..